This page covers the first hop: the code/message 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.

An OSF / REST API caller never sees any of this directly. DAS always translates it before passing it on — 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)

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 → DAS canonical message

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

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