Please take into account that there is no 1:1 match between TDA/PDX codes and "the REST API error". A single TDA/PDX code can be turned into different things depending on where you are looking at it: there are three distinct hops between the Office of First Filing (OFF) and the Office of Second Filing (OSF)/API caller, and each hop has its own code/message vocabulary.
OFF (TDA/PDX XML) ---------> WIPO DAS ---------> OSF / REST caller
"raw TDA code" \
+--> (a) push notification webhook
+--> (b) GET polling (status check / records)
This page is now just an index. The actual code/message tables live on the three sub-pages below, one per hop, because the fields returned and the vocabulary used are different in each case:
| # | Sub-page | Direction | When it applies | What you get |
|---|---|---|---|---|
| 1 | 5.1.1.- Responses from OFF to DAS (TDA/PDX codes) | OFF → DAS | A hosted OFF is forwarded a live retrieval/registration request and answers over the TDA/PDX protocol | Legacy numeric TDA/PDX code, and its migration mapping to the modern REST equivalent |
| 2 | 5.1.2.- Responses from DAS to OSF via notification endpoint | DAS → OSF (push) | The OSF is configured with the API exchange protocol and has registered a notificationUrl webhook with DAS | A JSON notification body containing a numeric errorCode and a statusMessage (EDI-style text) |
| 3 | 5.1.3.- Responses from DAS to OSF via GET | DAS → OSF (pull) | The OSF polls the REST status-check / registration-record / recorded-requests endpoints (this is what our Postman collections do) | No numeric errorCode field at all — only requestStatusCategory + a free-text requestStatusMessage; synchronous validation errors (bad request) use a separate code/details[] shape |