5.1.3.- Responses from DAS to OSF via GET

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

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 depends on who raised the error

• If the failure was raised by DAS's own validator (e.g. an OSF polls a retrieval it submitted with a mismatched access code) → you'll see the literal strings above (e.g. unmatched access code).
• 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.

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.

Quick reference: which page documents which field