This page helps an Office of First Filing (OFF) 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 — 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 reaches the OSF.
Sources: - das-app/src/app/das-tda-error-messages.ts — literal legacy TDA/PDX message text (left-hand columns below) - das/documents/postman/sampleYamlFileOffServices-draftSample_20260225.yaml — draft spec for the modern OFF Services REST interface (right-hand columns below)
⚠️ Status of the REST side: 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 REST columns below as "what an OFF should implement", not as an already-observed behaviour.⚠️ Scope: retrieval only. The draft's
PdxRequest.operationCategoryonly allowsretrieval— registration-related TDA codes (9, 10, 14, 15) have no REST equivalent defined and are out of scope here.
How the REST interface replaces the numeric code
Instead of a numeric TDA/PDX code, the OFF's REST endpoint reports status with:
requestStatusCategory: pending | success | error # coarse bucket statusMessage: free text # the actual "reason", e.g. "unmatched access code" errorCode: string (loosely typed, no fixed enum)
POST /v1/requests/notifications (DocumentNotificationRetrievalStatus), or returned directly on GET /v1/requests/retrievals (PdxResponse). The statusMessage vocabulary documented in the draft is word-for-word identical to the literal strings DAS already uses internally in das-status.ts (see 5.1.3, section B) — so an OFF implementing this spec should reuse exactly those strings.TDA/PDX code → REST equivalent an OFF should implement
| TDA/PDX code | Status type | TDA/PDX meaning as supplied | REST requestStatusCategory | REST statusMessage to send | Notes |
|---|---|---|---|---|---|
| 0 | 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 | ⚠️ 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-status | File is not available | error | document awaiting security clearance(best available match) | ⚠️ Gap: the REST vocabulary doesn't distinguish "awaiting clearance" (temporary) from "clearance permanently refused" |
| 3 | PDX-status | Documents was not found | 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 code 2 above — the draft has no separate "not authorized for public access" message |
| 6 | FWA-status | Delay in translation | n/a | n/a | Not in practical use — "Probably never used" |
| 7 | PDX-status | Oversize document/CD will be mailed | n/a | (no equivalent) | Not applicable under REST: large files are handled via presigned-URL upload/download (as in our registration/retrieval Postman collections), so there'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 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 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 | FWA-fault, PDX-fault | System not available, scheduled downtime | (synchronous error, not this vocabulary) | — | 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-fault | Received document cannot be imported | n/a | (no equivalent) | Not applicable under REST: this code exists only because the legacy protocol exchanges XML payloads. The REST interface exchanges structured JSON with no embedded document content, so there's nothing to "fail to import" in this sense |
| -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 |
Synchronous (request-level) errors — not part of the TDA code family
Separately from the status-message vocabulary above, the draft defines a plain request-validation error shape for when DAS calls the OFF's endpoint with bad/missing parameters (this is plumbing-level, not a translation of a TDA business code):
{
"code": 400,
"message": "Invalid input data or document",
"errorMessage": "DAS Access Code cannot be blank"
}
requesterOffice, documentNumber, documentDate, dasAccessCode, and requestAckId. Note the schema types code as an integer (echoing the HTTP status: 400/401/500), while the file's own notification-endpoint examples inconsistently use string codes (INVALID_INPUT_DATA, INVALID_TOKEN, TDA_SYSTEM_ERROR) for the same concept — flagged here as a draft inconsistency to resolve before this spec is finalized, not something to replicate.