This page covers the first hop: the code/message helps an Office of First Filing (OFF) sends back to WIPO DAS when DAS forwards it a live retrieval or registration-acknowledgement request. An OFF can do this over two different protocols, covered in two sections below.that currently answers WIPO DAS over the legacy TDA/PDX XML protocol figure out what to return instead if it implements the modern "OFF Services" REST interface.
Offices that still use TDA/PDX are connected to DAS through their own TDA/PDX endpoint, and already know their own numeric codes — nothing changes for them. This page exists purely as a migration reference: for each legacy TDA/PDX code, what should the equivalent REST response look like?
An OSF / REST API caller never sees any of this directly . DAS always translates it before passing it on — see — this is strictly the OFF↔DAS leg. See 5.1.2.- Responses from DAS to OSF via notification endpoint and 5.1.3.- Responses from DAS to OSF via GET for what actually reaches the caller.
Part A — Legacy TDA/PDX XML protocol (numeric codes)
OSF.
SourcesSource of truth (code, not documentation): - das-app/src/app/das-tda-error-messages.ts — literal legacy TDA/PDX message text - das-app/src/app/das-error-code-mappings.ts — the tdaSystemCodes[] arrays that map a TDA code to a DAS canonical message - das-app/src/app/das-error-codes.ts — the 6 top-level errorCode categories
TDA/PDX code → DAS canonical message
...
Known gaps / things to keep in mind when testing
- Overloaded codes (1, 18, -6) can't be told apart just from the TDA code — the real outcome depends on internal state DAS already has about the request. Don't assume a 1:1 mapping when writing test assertions.
- Unmapped codes (4, 6, 8, 9, 10, 13) exist in the ST.36/TDA specification but have no corresponding entry in
das-error-code-mappings.ts— if an OFF ever sends one of these, DAS has no specific translation for it. - Codes with no onward translation (7, 12) reach DAS but have an empty
ediSystemCodes[]entry, meaning there is currently no EDI message to forward to an OSF via the notification webhook (see 5.1.2). Code 12 is explicitly commented as obsolete.
Part B — Migrating to the modern "OFF Services" REST interface: what replaces each TDA/PDX code
Source:(left-hand columns below) - das/documents/postman/sampleYamlFileOffServices-draftSample_20260225.yaml — a draft spec for OFFs that want to answer DAS over plain REST/JSON instead of legacy TDA/PDX XML.the modern OFF Services REST interface (right-hand columns below)
⚠️ Status of the REST side⚠️ Status: draft, not yet live. In the current DAS backend, the only code touching this interface is a mock/test harness (
forward-retrieval-request-mock-service.ts, used by the internal automation-test suite) — no production office implements it yet. Treat the table REST columns below as "what an OFF should implement", not as a confirmed, an already-observed behaviour like Part A.⚠️ Scope: retrieval only. The draft's
PdxRequest.operationCategoryonly allowsretrieval— registration-related TDA codes (9, 10, 14, 15, -6) have no place in this interface at all REST equivalent defined and are out of scope for this mappinghere.
How the REST interface replaces the numeric code
...
TDA/PDX code → REST equivalent an OFF should implement
| TDA/PDX code | Status type | TDA/PDX meaning as suppliedLegacy meaning | REST requestStatusCategory | REST statusMessage to send | Notes | |||||
|---|---|---|---|---|---|---|---|---|---|---|
| 0 (retrieval success) | FWA-status, PDX-status | No Error / Successful | success | ready for download → delivered (two-stage) | Report ready for download once the file/URL is available, delivered once retrieved | |||||
| 1 | FWA/PDX/DAS-status | Application number provided was not found | error | document number not available | Direct equivalent | ⚠️ This code is ambiguous even in the legacy protocol itself — some implementations also use it for "document withdrawn" or a generic missing-field condition. Pick the REST statusMessage that matches the actual situation, not just the historical code value | ||||
| 2 | FWA-status, PDX-status2 | File is not available (security clearance not granted) | error | document awaiting security clearance(best available match) | ⚠️ Gap: this REST phrase reads as "pending", but TDA 2 is a permanent refusal. The draft the REST vocabulary doesn't distinguish "awaiting clearance" (temporary) from "clearance permanently denied" — OFFs will need to reuse the same phrase for both until the draft is refinedrefused" | |||||
| 3 | PDX-status3 | Documents was not found (incomplete set) | error | document incomplete | Direct equivalent | |||||
| 4 | FWA-status | Document content could not be retrieved | n/a | n/a | Not in practical use — "Probably not used as TDA Error 3 is similar" | |||||
| 5 | PDX-status | Not published, no authorization to permit access filed | error | document awaiting security clearance(best available match) | ⚠️ Gap: same REST phrase as TDA code 2 above — the draft has no separate "not authorized for public access" status, so this and TDA 2 collapse into one REST messagemessage | |||||
| 6 | FWA-status | Delay in translation | n/a | n/a | Not in practical use — "Probably never used" | |||||
| 7 | PDX-status | Oversize document/ | 7 | Oversize document, CD will be mailed | n/a | (no equivalent — see note) | Not applicable under REST: large files are handled via presigned-URL upload/download (as in the our registration/retrieval Postman collections), so there is 's no "oversize/CD mailed" concept any more | |||
| 8 | FWA-status | Request less than 1000 pages per transaction | n/a | n/a | Not in practical use — "Probably not used, instead TDA Error 7 was reported" | |||||
| 9 | DAS-status | Registered | n/a | n/a | DAS-internal status, not a counterpart reply code from an OFF — no action needed | |||||
| 10 | DAS-status | Not Registered | n/a | n/a | DAS-internal only | |||||
| 11 | PDX-status | Das Access Code invalid | error | unmatched access code | Direct equivalent | |||||
| 12 | PDX-status | Request under processing, response sent later | pending | awaiting off response | This is really just the default pending state while the OFF works on the request, not a distinct error | |||||
| 13 | PDX-status | Application number does not correspond with bibliographic data | n/a | n/a | Rarely used — DAS rejects an OSF request with mismatched data before it would reach this point | |||||
| 14 | DAS-status | Successfully Registered DAS to OFF only | n/a | n/a | Registration-only — out of scope (this draft covers retrieval only) | |||||
| 15 | DAS-status | Successfully Updated DAS to OFF only | n/a | n/a | Registration-only — out of scope | |||||
| 16 | DAS-status | Das Access Code and Priority Date did not match | error | unmatched document date and access code | Exact equivalent — the draft vocabulary has a dedicated phrase for this combined case | |||||
| 17 | DAS-status | Priority Date did not match | error | unmatched document date | Direct equivalent | |||||
| 18 | DAS-status | Das Access Code did not match | error | unmatched access code | Direct equivalent | |||||
| 19 | DAS-status | Priority Date was not provided by OFF | error | invalid document details(closest match) | ⚠️ Gap: the draft REST vocabulary doesn't distinguish "missing" from "mismatched" date — ; unmatched document date would also be defensible ; — needs clarification with DAS Support before an OFF implements it | |||||
| -1 / -2 | FWA-fault, PDX-fault | System not available (, scheduled downtime / back-end problem) | (synchronous error, not this vocabulary)n/a — not part of the async statusMessage vocabulary | — | Report via Use the synchronous error shape instead: code: TDA_SYSTEM_ERROR, message: "TDA SYSTEM ERROR" (HTTP 500), per the draft's exampleOfError500 | |||||
| -2 | FWA-fault, PDX-fault | System not available, back-end problem | (synchronous error, not this vocabulary) | — | Same as -1 | |||||
| -3 | PDX-fault3 / -4 / -5 | Received document cannot be imported / XML input / output processing failure | n/a | (no equivalent — see note) | Not applicable under REST: these codes exist this code exists only because the legacy protocol exchanges XML payloads. The REST interface exchanges structured JSON with no embedded document content, so there is 's nothing to "fail to import/parse" in this sense. If sample data genuinely can't be matched, use invalid document details instead | |||||
| -4 | FWA-fault, PDX-fault | XML input processing failure | n/a | (no equivalent) | Same reasoning as -3 | |||||
| -5 | FWA-fault, PDX-fault | XML output processing failure | n/a | (no equivalent) | Same reasoning as -3 | 4, 6, 8, 9, 10, 13 | (already unmapped/unused in Part A) | — | — | Remain unmapped; no REST equivalent needed |
Synchronous (request-level) errors — not part of the TDA code family
...