5.1.2.- Responses from DAS to OSF via notification endpoint

This page covers the second hop: how WIPO DAS reports a result to an OSF over the optional push-notification webhook.

When this applies

Only when both are true: - the OSF's third-party configuration uses the API exchange protocol (EXCHANGE_PROTOCOL_API), and - the OSF has registered a notificationUrl with DAS Support.

If either condition is false, DAS never calls out to the OSF — the OSF must poll instead (see 5.1.3.- Responses from DAS to OSF via GET).

if (protocol === EXCHANGE_PROTOCOL_API && notificationUrl) {
    postNotificationToOffice(notificationUrl, notification)
}

das-retrieval-service.ts / sm-rest-retrieval-service.ts)

Payload shape

export type DocumentNotifications = {
  systemId: string,
  notificationCategory: string,
  dateTime: string,
  totalQuantity: number,
  documentRetrievalRequestStatusBag?: DocumentRetrievalRequestStatus[];
}

export type DocumentRetrievalRequestStatus = {
  requestAckId: string | null,
  requestStatusCategory: string,
  errorCode?: string | null,     // numeric EDI code, e.g. "-6"
  statusMessage?: string | null  // EDI message text, e.g. "ACCESS NOT AUTHORIZED"
};

This is the only DAS→OSF channel that carries a numeric error code at all. It is not the same errorCode enum (INVALID_INPUT_DATA, OPERATION_FORBIDDEN, ...) used for synchronous REST validation errors — it's the legacy EDI numeric code, produced by re-translating the TDA/PDX code through getEDICodeByTDACode() / getEDIMessageByTDACode().

Example payloads

Success:

{
  "systemId": "WIPO_DAS",
  "notificationCategory": "available",
  "dateTime": "2026-10-19T10:00:00.000Z",
  "totalQuantity": 1,
  "documentRetrievalRequestStatusBag": [
    { "requestAckId": "USIB20260101010101", "requestStatusCategory": "success" }
  ]
}

Error — hosted OFF responded with TDA code 5 ("Not published, no authorization to permit access filed"):

{
  "systemId": "WIPO_DAS",
  "notificationCategory": "available",
  "dateTime": "2026-10-19T10:00:00.000Z",
  "totalQuantity": 1,
  "documentRetrievalRequestStatusBag": [
    {
      "requestAckId": "USIB20260101010101",
      "requestStatusCategory": "failure",
      "errorCode": "-6",
      "statusMessage": "ACCESS NOT AUTHORIZED"
    }
  ]
}

TDA/PDX code → what the OSF actually receives in the notification

TDA code	TDA/PDX meaning	`errorCode` sent	`statusMessage` sent
0 / 14 / 15	Successful / Registered / Updated	0	`Operation Successful`
1	Application number not found (or withdrawn/missing-field, see 5.1.1)	-7	`APPLICATION NUMBER NOT FOUND` — ⚠️ even the "document withdrawn" case ends up with this same generic text
2	File is not available (security)	-8	`FILE WAS NOT AVAILABLE (REQUESTED APPLICATION EXISTS BUT IS NOT CLEARED FOR DISSEMINATION, e.g. security)`
3	Document(s) not found	-9	`DOCUMENT(S) WAS NOT AVAILABLE (COMPLETE SET OF REQUIRED DOCUMENTS FOR CERTIFIED COPY IS NOT AVAILABLE)`
5	Not published / no authorization	-6	`ACCESS NOT AUTHORIZED`
7	Oversize document, CD will be mailed	(none)	(none — `getEDIMessageByTDACode(7)` returns `undefined`, no EDI entry defined)
11	ACC invalid	-4	`INVALID DATA`
12	Request under processing	(none)	(none — no EDI entry; also flagged obsolete in the code)
16	ACC and priority date mismatch	-15	`MISMATCH ACCESS CODE AND PRIORITY FILING DATE`
17	Priority date mismatch	-12	`MISMATCH PRIORITY FILING DATE OR ACCESS CODE`
18	ACC mismatch (or missing, reused)	-14	`MISMATCH ACCESS CODE`
19	Priority date not provided	-13	`MISSING PRIORITY FILING DATE`
-1	System scheduled downtime	(none)	(none — no EDI entry)
-2	System unavailable (back-end)	(none)	(none — no EDI entry)
-6	XML output processing failure (duplicate doc / already registered)	-1	`DUPLICATE (ENTRY ALREADY EXISTS)`

Caveats

Lossy translation: because the reverse mapping only keeps a single defaultReverseMapping per TDA code, distinct real-world situations can collapse into one generic EDI phrase (e.g. TDA 1 for a withdrawn document still produces APPLICATION NUMBER NOT FOUND).
Missing EDI entries: OPERATION_IN_PROGRESS (oversize 7) and DAS_SYSTEM_ERROR (-1, -2) have no EDI translation registered — the notification fields are simply absent for these.
This only fires for requests answered via the TDA/PDX protocol. If the office responded over plain REST/API instead, DAS forwards the raw errorMessage/errorCode it received, unmodified.
If the OSF is not registered for push notifications, none of this applies — they must poll instead, see 5.1.3.- Responses from DAS to OSF via GET.

Page tree