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).
Payload shape
...
...
Payload shape
...
if (protocol === EXCHANGE_PROTOCOL_API && notificationUrl) {
postNotificationToOffice(notificationUrl, notification)
} |
|
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": "USIB20260101010101",
string | null,
"requestStatusCategory": string,
"success | errorCode?: stringpending | nullerror",
// numeric EDI "errorCode": "numeric 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:
...
...
{
"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
...
you receive in the notification today (
...
office on legacy TDA/PDX)
| TDA code | TDA/PDX meaning | errorCode |
|---|
sent 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 entryXML output processing failure (duplicate | Duplicate doc / already registered (registration only) | -1 | DUPLICATE (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 |
|---|
|
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)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.
...
...
Caveats (legacy TDA/PDX translation)
...
