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.

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)Sample exchange over the new REST interface

Instead of a numeric TDA/PDX code, an OFF implementing REST 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

Part A — Legacy TDA/PDX XML protocol (numeric codes)

Source of truth (code, not documentation): - das-app/src/app/das-tda-error-messages.ts — literal 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	Status type	TDA/PDX meaning as supplied

DAS canonical messageDAS sub-codeDAS errorCode category

REST requestStatusCategory	REST statusMessage to send	Notes
0	FWA-status, PDX-status	No Error / Successful

Successful.0SUCCESS

success

ready for download → delivered (two-stage)

Report ready for download once the file/URL is available, delivered once retrieved

code 0 is reused for 0 / 14 / 15

1	FWA/PDX/DAS-status	Application number provided was not found	error

Application

document number

provided was

not

found.-4, -7, or -5 (see note)INVALID_INPUT_DATA or OPERATION_FORBIDDEN⚠️ Overloaded: the backend reuses TDA code 1 for three different outcomes depending on internal context: generic invalid input (-4), "document not found" (-7), and "document withdrawn" (-5, under OPERATION_FORBIDDEN)

available	This code may also represent "document withdrawn" or a generic missing-field condition — send the message matching the actual situation
2	FWA-status, PDX-status	File is not available

File is not available. (security clearance not granted)-8OPERATION_FORBIDDEN

	error	document awaiting security clearance	Closest available match; the REST vocabulary does not distinguish a temporary "awaiting clearance" from a permanent refusal
3	PDX-status	Documents was not found

Document(s) was not found.-9OPERATION_FORBIDDEN

error	document incomplete
4	FWA-status	Document content could not be retrieved

—(not mapped)(none)

n/a

n/a

Not used in practice — TDA Error

Not wired up in code; probably unused, as TDA

3 covers the same situation
5	PDX-status	Not published, no authorization to permit access filed

File is not available to the public, and no authorization to permit access has been filed.-6OPERATION_FORBIDDEN6

	error	document awaiting security clearance	Same REST phrase as code 2 — no separate "not authorized for public access" message exists
6	FWA-status	Delay in translation

—(not mapped)(none)Not wired up in code; probably never used (do not confuse with code -6 below, which is a different, negative code)-6(missing from the original table entirely)XML output processing failure (reused as a generic technical-error code)Duplicate document received / File already uploaded and registered-1 or -107INVALID_INPUT_DATA or OPERATION_FORBIDDEN⚠️ Actively used by the backend for two different outcomes (duplicate document vs. already-registered file), but was never documented on the old matching table. Registration-only — not applicable to retrieval

n/a	n/a	Not used in practice
7	PDX-status	Oversize document/CD will be mailed

Oversize Document – CD will be mailed.-201OPERATION_IN_PROGRESSSee 5.1.2 — no EDI translation exists for this code, so it isn't actually forwarded via the notification webhook today

n/a	(no equivalent)	Not applicable under REST: large files are handled via presigned-URL upload/download
8	FWA-status	Request less than 1000 pages per transaction

—(not mapped)(none)

n/a

n/a

Not used in practice

Not wired up; probably unused

— 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
10	DAS-status	Not Registered

—

n/a

n/a

DAS-internal

Internal only
11	PDX-status	Das Access Code invalid

ACC invalid.-4

error

unmatched access code

INVALID_INPUT_DATA

12	PDX-status	Request under processing, response sent later

The request is under processing, the response will be sent later.-202OPERATION_IN_PROGRESSCode comment marks this "obsolete now... not implemented on DAS side, also we don't expect it from TDA side"(not mapped)

	pending	awaiting off response	Default pending state while the OFF works on the request
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

Successfully Registered.0SUCCESS

n/a

n/a

Registration-only —

not applicable to retrieval

out of scope (this interface covers retrieval only)
15	DAS-status	Successfully Updated DAS to OFF only

Successfully Updated.0SUCCESS

n/a

n/a

Registration-only —

not applicable to retrieval

out of scope
16	DAS-status	Das Access Code and Priority Date did not match

ACC and Priority Date did not match.-15

error

unmatched document date and access code

INVALID_INPUT_DATA

17	DAS-status	Priority Date did not match

Priority Date did not match.-12INVALID_INPUT_DATA

error	unmatched document date
18	DAS-status	Das Access Code did not match

ACC did not match.-14 or -13 (see note)INVALID_INPUT_DATA⚠️ Overloaded: same TDA code used both for

error

unmatched access code

"mismatched access code" (-14) and "missing access code" (-13)

19	DAS-status	Priority Date was not provided by OFF

Priority Date was not provided by OFF.-13

error

invalid document details

Closest available match — there is no separate "missing" vs. "mismatched" date message

INVALID_INPUT_DATA

-1	FWA-fault, PDX-fault	System not available, scheduled downtime

System is not available due to scheduled downtime.-101

(reported as a system error, not this vocabulary)

—

Use code: TDA_SYSTEM_ERROR, message: "TDA SYSTEM ERROR" on the request itself (HTTP 500)

DAS_SYSTEM_ERROR

-2	FWA-fault, PDX-fault	System not available, back-end problem

System is not available due to system problem.-101

(reported as a system error, not this vocabulary)

—

Same as -1

DAS_SYSTEM_ERROR

-3	PDX-fault	Received document cannot be imported

The received document can not be imported.-2INVALID_INPUT_DATA

n/a

(no equivalent)

No longer applicable: the REST interface exchanges plain identification data, not document content

Resolves to the "invalid document file format" sub-code, not a generic -3

-4	FWA-fault, PDX-fault	XML input processing failure

XML input processing failure-3INVALID_INPUT_DATA

n/a

(no equivalent)

Same as -3

Covers corrupted file / invalid ST.26 package / checksum mismatch / virus infected

-5	FWA-fault, PDX-fault	XML output processing failure

XML output processing failure-3INVALID_INPUT_DATAUsed specifically for the "file not available" sub-case

Known gaps / things to keep in mind when testing

1. 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.
2. 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.
3. 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: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.

⚠️ 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 below as "what an OFF should implement", not as a confirmed, already-observed behaviour like Part A.

⚠️ Scope: retrieval only. The draft's PdxRequest.operationCategory only allows retrieval — registration-related TDA codes (9, 10, 14, 15, -6) have no place in this interface at all and are out of scope for this mapping.

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)

TDA/PDX code → REST equivalent an OFF should implement

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"
}

...