Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Simplify to tables + samples only; remove internal code/file references and implementation caveats

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 is configured for API-based exchange and has registered a notificationUrl notification URL with DAS Support. If either condition is false, DAS never calls out to not, the OSF — the OSF must poll instead (— see 5.1.3.- Responses from DAS to OSF via GET).

Code Block
themeDefault
languagenone
if (protocol === EXCHANGE_PROTOCOL_API && notificationUrl) {
    postNotificationToOffice(notificationUrl, notification)
}
das-retrieval-service.ts / sm-rest-retrieval-service.ts)

Payload shape

Code Block
themeDefault
languagenonejson
export type DocumentNotifications = {
  "systemId": string"WIPO_DAS",
  "notificationCategory": string"available",
  "dateTime": string"2026-10-19T10:00:00.000Z",
  "totalQuantity": number1,
  "documentRetrievalRequestStatusBag?": DocumentRetrievalRequestStatus[];
}

export type DocumentRetrievalRequestStatus = {
      "requestAckId": string | null,
"USIB20260101010101",
      "requestStatusCategory": string,
"success | errorCode?: stringpending | nullerror",
     //  "errorCode": "numeric EDI code, e.g. "-6"only present for errors",
  statusMessage?: string | null  // EDI message text, e.g. "ACCESS NOT AUTHORIZED"
};"statusMessage": "human-readable text"
    }
  ]
}

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:

Code Block
themeDefault
languagejson
{
  "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"):

Code Block
themeDefault
languagejson
{
  "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

...

you receive in the notification today (

...

office on legacy TDA/PDX)

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

🆕 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:

Code Block
themeDefault
languagenone
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;
}
sm-rest-retrieval-service.ts)

Same table, once the office migrates to the new REST interface

Once an office answers over the newer REST interface instead of TDA/PDX (see Once an OFF implements the draft REST interface instead (5.1.1.- Responses from OFF to DAS (TDA/PDX codes)), DAS stops translating anything — the notification carries whatever errorCode/statusMessage the OFF that office's own REST endpoint sends is forwarded to the OSF verbatim.system sends — there is no fixed numeric code on this path, and errorCode is typically left empty.

TDA/PDX code (for reference)errorCode after migrationstatusMessage after migration
0 / 14 / 15(empty)ready for download → delivered
1(empty)document number not available
2(empty)document awaiting security clearance
3(empty)document incomplete
5(empty)document awaiting security clearance
7(empty)(not applicable)
11(empty)unmatched access code
12(empty)awaiting off response
16(empty)unmatched document date and access code
17(empty)unmatched document date
18(empty)unmatched access code
19(empty)invalid document details
-1 / -2(reported as a system error instead)(reported as a system error instead)
Today (OFF on TDA/PDX)After migration (OFF on REST, per the draft)
Translation stepTDA numeric code → EDI numeric code/message, via the fixed lookup table aboveNone — DAS passes through whatever the OFF sent
errorCodeFixed legacy EDI number (e.g. -6)Whatever the OFF's REST endpoint put in errorCode — the draft types this as a loosely-defined string with no fixed enum. In every example in the draft itself, errorCode is null; only statusMessage actually carries information
statusMessageLegacy ALL-CAPS EDI phrase (e.g. "ACCESS NOT AUTHORIZED")Whatever free text the OFF sent — expected, per the draft, to reuse the same vocabulary DAS itself uses internally (das-status.ts), e.g. "document awaiting security clearance" instead of "ACCESS NOT AUTHORIZED"
Consistency guaranteeStrong — DAS controls the translation table, so the vocabulary is fixed and documented above⚠️ Weak — since nothing is validated or translated, the OSF only gets whatever text that specific OFF chose to send. Treat statusMessage as advisory/free text, not a stable enum, until the draft defines and enforces a closed vocabulary

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)

...