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)
}

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 today (OFF on legacy TDA/PDX)

🆕 What changes once this OFF migrates from TDA/PDX to REST

This EDI-translation step only happens for offices answering over the TDA/PDX protocol:

if ('tda' == event.respondingProtocol) {
    let ediErrorMsg = getEDIMessageByTDACode(parseInt(errorCode));
    ediCode        = getEDICodeByTDACode(parseInt(errorCode));
    data.documentRetrievalRequestStatusBag[0].errorCode = ediCode;
    data.documentRetrievalRequestStatusBag[0].statusMessage = ediErrorMsg;
} else {
    // REST / remote OFF: passed through AS-IS, no translation at all
    data.documentRetrievalRequestStatusBag[0].errorCode = errorCode;
    data.documentRetrievalRequestStatusBag[0].statusMessage = errorMessage;
}

Once an OFF implements the draft REST interface instead (5.1.1.- Responses from OFF to DAS (TDA/PDX codes)), DAS stops translating anything — whatever errorCode/statusMessage the OFF's own REST endpoint sends is forwarded to the OSF verbatim.

Worked example — TDA code 5 ("Not published, no authorization to permit access filed"): - Today: errorCode: "-6", statusMessage: "ACCESS NOT AUTHORIZED" - After migration (per the 5.1.1 migration table): errorCode: null, statusMessage: "document awaiting security clearance" (the OFF's own choice — no guarantee it matches exactly this text until the vocabulary is formally closed)

Caveats (legacy TDA/PDX translation)

1. 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).
2. 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.
3. 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 (see migration section above).
4. 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.