This page covers the third hop: what an OSF actually sees when it uses the REST API in pull mode — i.e. submitting a request and then calling GET endpoints to check its status. This is the model used by our Postman collections (c.- WIPO DAS REST API V2 Validation Test, c.- WIPO DAS REST API V2 Registration process Hosted OFF).

There are two unrelated situations here, with two different response shapes. Don't confuse them.

A. Synchronous validation errors (the request itself was rejected)

This happens immediately, on the call that submits the request (e.g. POST /requests/registrations, POST /requests/retrievals, POST /requests/files/url-uploads) when the input is malformed, mismatched, or unauthorized. It returns a 4xx HTTP status with this body shape:

{
  "code": "INVALID_INPUT_DATA",
  "message": "Invalid input data or document",
  "details": [
    { "code": -4, "message": "Mismatched access code: dasAccessCode: expected dasAccessCode=AB46" }
  ]
}

code is one of the 6 top-level DASSystemCodes (SUCCESS, INVALID_INPUT_DATA, OPERATION_FORBIDDEN, DAS_SYSTEM_ERROR, OPERATION_IN_PROGRESS, INVALID_TOKEN). details[].message is built by a single shared formatter (gererateErrorDetail in app/utils.ts):

<ErrorMessage text>[: <attributeName>[=<attributeValue>]][: expected <attributeName>=<expectedValue>]

This section is about OSF input validation, unrelated to the OFF's protocol (TDA/PDX vs REST) — it does not change when an OFF migrates.

Common message templates

The illustrative comments in the OpenAPI yaml ("...received fileFormatCategory=jpg -> expected fileFormatCategory=[pdf, zip]") are paraphrased, not literal strings — the real formatter always produces the colon/"expected" pattern above.

⚠️ Security redaction: the "expected" value can be hidden

In das-validation-rules.ts:

return isDasSupportUser(authInfo) || !isAccessCodeValid
    ? dasErrors
    : filterErrorsForExpectedValue(dasErrors);

B. Asynchronous status polling (the request was accepted; you're checking what happened to it)

This covers GET .../requests/retrievals/statuses, GET .../requests/registrations (record), and the bulk recordedDocumentRequestBag list. These return HTTP 200 even when the underlying operation failed — the failure is only visible in the body.

// retrieve-request-status.ts  (single retrieval status check)
requestStatusCategory: string;
requestStatusMessage?: string;
error?: string;
// NOTE: there is no errorCode field in this type

// reterive-registration-record.ts (registration record)
requestStatusCategory: string;
// NOTE: no errorCode field here either

// retrieve-collection-recorded-request.ts (bulk list)
requestStatusCategory: string;
// NOTE: no errorCode field here either

There is no numeric errorCode field anywhere in the polling responses. The only channel that carries one is the push notification webhook (see 5.1.2). What you do get is a free-text requestStatusMessage, sourced from das-status.ts.

Literal requestStatusCategory / requestStatusMessage values you may see (retrieval)

Literal values you may see (registration)

Where the message text comes from today, for a hosted OFF on TDA/PDX

If the failure originated from a hosted OFF answering over TDA/PDX → requestStatusMessage is overwritten with the EDI-translated text documented on 5.1.2 (e.g. "ACCESS NOT AUTHORIZED" for TDA code 5), because OSF_LAST_MESSAGE is set to that EDI string regardless of which channel (push or pull) ends up reading it.

If the failure was raised by DAS's own validator instead (e.g. an OSF polls a retrieval it submitted with a mismatched access code, unrelated to any OFF) → you'll see the literal strings in the tables above directly (e.g. unmatched access code).

So the same underlying TDA failure can appear as "ACCESS NOT AUTHORIZED" to a polling OSF, and as errorCode: -6, statusMessage: "ACCESS NOT AUTHORIZED" to a webhook-registered OSF — same text, but only the webhook gets the numeric code.

🆕 What changes once this OFF migrates from TDA/PDX to REST

Just like on the notification channel (5.1.2), OSF_LAST_MESSAGE (which becomes requestStatusMessage here) is only EDI-translated when event.respondingProtocol == 'tda'. Once the OFF answers over the draft REST interface instead (5.1.1), the raw statusMessage the OFF sent is stored and returned as-is — no EDI translation step runs at all.

Worked example — same underlying failure (TDA code 5 equivalent), polled via GET: - Today: {"requestStatusCategory": "error", "requestStatusMessage": "ACCESS NOT AUTHORIZED"} - After migration: {"requestStatusCategory": "error", "requestStatusMessage": "document awaiting security clearance"} (assuming the OFF implements the draft vocabulary as documented on 5.1.1)

Quick reference: which page documents which field