Page History

This page covers the third hop: what an OSF actually sees receives when it uses using 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 Returned 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 shapeHTTP status is 4xx.

Example request:

POST /requests/registrations
{
  "operationCategory": "registration",
  "documentKindCategory": "patent",
  "documentNumber": "IB PCT/IB2026/098496",
  "documentDate": "2026-02-08",
  "dasAccessCode": "1234",
  "email": "jjduffy@example.com",
  "fileId": "US-bf5f35ff-2a94-4082-8c1c-02e321178232"
}

Example response (HTTP 400):

{
  "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 the error category (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

lists one or more specific reasons.

Message you will receive, per situation

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

...

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

...

Note: when the access code you supplied is incorrect, the response will not reveal the correct value, for security reasons — you will only see the field name, not the "expected" value.

...

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

This covers Covers GET .../requests/retrievals/statuses, GET .../requests/registrations (record), and the bulk recordedDocumentRequestBag recorded-requests list. These return HTTP 200 even when the underlying operation failed or is still pending — the failure result is only visible in the body, via requestStatusCategory and requestStatusMessage. There is no numeric error code on this channel.

Example request:

GET /

...

requests/retrievals/statuses?requestAckId=USIB20260101010101

Example response — pending:

{
  "requestAckId": "USIB20260101010101",
  "requestStatusCategory": "pending",
  "requestStatusMessage": "awaiting off response"
}

Example response — error:

{
  "requestAckId": "USIB20260101010101",
  "requestStatusCategory": "error",
  "requestStatusMessage": "unmatched access code"
}

Values you

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.

...

may see (retrieval)

...

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.

...

Retrieval failures from a hosted OFF: legacy TDA/PDX code vs. the message you will actually receive

When the failure comes from a hosted Office of First Filing, the requestStatusMessage you see on this poll depends on which protocol that office uses to answer. The table below matches each legacy TDA/PDX code to the message you receive today (office still on TDA/PDX) and the message you can expect once that office migrates to the newer REST interface (see 5.1.1.- Responses from OFF to DAS (TDA/PDX codes) for the full legacy-code reference, and 5.1.2.- Responses from DAS to OSF via notification endpoint for the equivalent on the push-notification channel).

Quick reference