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 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?

...

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

...

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.

...

requesting office (OSF)Sample exchange over the new REST interface

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

...

POST /v1/requests/notifications
{
  "systemId": "<office code>",
  "notificationCategory": "document availability",
  "dateTime": "2026-02-25T12:23:24Z",
  "totalQuantity": 1,
  "documentNotificationRetrievalStatusBag": [
    {
      "requestAckId": "USIB20210523120902",
      "requestStatusCategory": "error",
      "errorCode": null,
   

...

...

...

 "

...

statusMessage"

...

: 

...

"unmatched access code"

...

...

...

...

...

}
 

...

...

]
}

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

(best

Closest 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)⚠️ Gap: same

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 code

Direct 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 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

Closest available match — there is no separate "missing"

from

vs. "mismatched" date

; unmatched document date would also be defensible — needs clarification with DAS Support before an OFF implements it

message
-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 sense

plain 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 shape:

...

{
  "code": 400,
  "message": "Invalid input data or document",
  "errorMessage": "DAS Access Code cannot be blank"
}

...