Page History

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

...

keep using their own numeric codes — nothing changes for them. This page

...

is purely

...

a migration reference: for each legacy TDA/PDX code, what should the equivalent REST response look like?

...

This only concerns the OFF↔DAS exchange. 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 requesting office (OSF

...

).

This REST interface is still a draft. It is retrieval-only (registration is not covered) and is not required or supported by WIPO DAS today — treat the table below as "what to implement," not as an already-available service.

Sample exchange over the new REST interface

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.operationCategory only allows retrieval — registration-related TDA codes (9, 10, 14, 15) have no REST equivalent defined and are out of scope here.

...

Instead of a numeric TDA/PDX code, the an OFF 's implementing REST endpoint reports status with plain fields:

Code Block
theme Default language yaml json
POST /v1/requests/notifications { "systemId": "<office code>", "notificationCategory": "document availability", "dateTime": "2026-02-25T12:23:24Z", "totalQuantity": 1, "documentNotificationRetrievalStatusBag": [ { requestStatusCategory: pending | success | error # coarse bucket statusMessage: free text "requestAckId": "USIB20210523120902", "requestStatusCategory": "error", "errorCode": null, # the actual "reason", e.g.statusMessage": "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

...

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 may also represent "document withdrawn" or a generic missing-field condition . Pick the REST statusMessage that matches — send the message matching the actual situation, not just the historical code value
2	FWA-status, PDX-status	File is not available	error	document awaiting security clearance	Closest (best available match)⚠️ Gap: ; the REST vocabulary doesn't distinguish does not distinguish a temporary "awaiting clearance" (temporary) from "clearance permanently refused"from a permanent refusal
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 used in practical use — "Probably not used as practice — TDA Error 3 is similar"covers the same situation
5	PDX-status	Not published, no authorization to permit access filed	error	document awaiting security clearance(best available match)	Same ⚠️ Gap: same REST phrase as code 2 above — the draft has no separate "not authorized for public access" message exists
6	FWA-status	Delay in translation	n/a	n/a	Not in practical use — "Probably never used"used in practice
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 used in practical use — "Probably not used, instead TDA Error 7 was reported"practice — TDA code 7 is reported instead
9	DAS-status	Registered	n/a	n/a	DAS-internal Internal status only, not a counterpart reply code from an OFF — no action needed
10	DAS-status	Not Registered	n/a	n/a	DAS-internal Internal only
11	PDX-status	Das Access Code invalid	error	unmatched access codeDirect equivalent
12	PDX-status	Request under processing, response sent later	pending	awaiting off response	This is really just the default 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 interface 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 dateDirect equivalent
18	DAS-status	Das Access Code did not match	error	unmatched access codeDirect equivalent
19	DAS-status	Priority Date was not provided by OFF	error	invalid document details(closest match)	Closest available match — there is no separate ⚠️ Gap: the REST vocabulary doesn't distinguish "missing" from vs. "mismatched" date ; unmatched document date would also be defensible — needs clarification with DAS Support before an OFF implements itmessage
-1	FWA-fault, PDX-fault	System not available, scheduled downtime	(synchronous reported as a system error, not this vocabulary)	—	Use the synchronous error shape instead: code: TDA_SYSTEM_ERROR, message: "TDA SYSTEM ERROR" on the request itself (HTTP 500), per the draft's exampleOfError500
-2	FWA-fault, PDX-fault	System not available, back-end problem	(synchronous reported as a system error, not this vocabulary)	—	Same as -1
-3	PDX-fault	Received document cannot be imported	n/a	(no equivalent)	Not No longer 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 senseplain identification data, not document content
-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

Sample of a system-level error (request rejected before it is even processed)

{
  "code": "TDA_SYSTEM_ERROR",
  "message": "TDA SYSTEM ERROR",
  "details": [
    { "message": "Unexpected internal error", "code": 500 }
  ]
}

Other examples of this shapeSeparately 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"
}