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

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

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)

...

Retrieval failures from a hosted OFF

...

: legacy TDA/PDX

...

code vs. the message you will actually receive

When If the failure originated comes 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.

...

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

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)

...

Field you see	Where it's documented
code, details[].code, details[].message (HTTP 4xx on submission)	This page, section A
requestStatusCategory, requestStatusMessage (HTTP 200 on poll)	This page, section B
errorCode, statusMessage (push notification body)	5.1.2.- Responses from DAS to OSF via notification endpoint
Legacy TDA/PDX numeric code, and its REST migration mapping (OFF→DAS only, never seen by the OSF directly)	5.1.1.- Responses from OFF to DAS (TDA/PDX codes)