Every error response from the AUO API uses the same JSON envelope, regardless of the HTTP status code.

​
Error envelope

{
  "error": {
    "type": "invalid_request",
    "message": "abn must be an 11-digit string.",
    "request_id": "req_01abc..."
  }
}
All three fields are always present:
  • type: a stable machine-readable code (see the table below).
  • message: a human-readable description of what went wrong.
  • request_id: a unique identifier for this request. Quote it when contacting support.

​
Error types

HTTP statustypeMeaning
400invalid_requestThe request body or parameters are malformed or fail validation. Fix the request before retrying.
401unauthorizedThe bearer token is missing, invalid, or has been rolled. Check your Authorization header.
404not_foundThe resource (e.g. a watch subscription) does not exist.
429rate_limitedToo many requests. Back off and retry after the indicated delay.
500internalAn unexpected server error. Safe to retry; if it persists, contact support with the request_id.
502internalThe upstream identity source (ABR) is temporarily unavailable. Message: “identity source temporarily unavailable”. Safe to retry.

​
Absent entity is not an error

A common source of confusion: if an ABN, ACN, or name simply does not appear in the government source, AUO returns a clean 200 with an empty candidates array. 
{
  "query": { "abn": "00000000000" },
  "candidates": [],
  "disclaimer": "..."
}
This is the expected response for an entity that ABR has no record of. It is not an error, so there is no error envelope, and no retry is needed. Only an upstream outage returns a 502. The distinction matters: an empty candidates array means “not found in the source”, while a 502 means “we could not reach the source.”

​
Screening and read failures

For POST /v1/screen (and the screening block inside /v1/resolve), a failure to read the watchlist index returns unavailable for the affected source, never a false no_match. This fail-safe is intentional: a read error must never look like a clean result. 
{
  "screening": {
    "dfat_sanctions": { "status": "unavailable" },
    "asic_banned_person": { "status": "unavailable" }
  }
}
If you see unavailable, retry the request. If it persists, contact support with the request_id.

​
Using the request_id

Every response (successful or error) includes a request_id in the error envelope for errors. Copy the full request_id value (it starts with req_) when reporting an issue. It lets the support team look up the exact request in the logs without needing any other context.

​
Retry guidance

  • 502 (identity source unavailable): retry with exponential backoff. The ABR SOAP service is occasionally unavailable for short periods.
  • 500 (internal): retry once after a brief delay. If it persists, contact support.
  • 429 (rate limited): back off for the indicated interval, then retry.
  • 400 (invalid request): the request is malformed. A retry with the same payload will get the same error. Fix the input, then retry.
  • 401 (unauthorized): the token is invalid or missing. Check your Authorization header. Rolling a key invalidates the old one immediately.
  • 404 (not found): the resource does not exist. Retrying will not create it.

​
Example: handling errors in code

const res = await fetch("https://api.auo.com.au/v1/resolve", {
  method: "POST",
  headers: {
    Authorization: "Bearer auo_sk_live_your_key_here",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ abn: "51824753556" }),
});

if (!res.ok) {
  const { error } = await res.json();
  // Log error.request_id for support
  console.error(`${error.type}: ${error.message} (${error.request_id})`);
  throw new Error(error.type);
}

const data = await res.json();
// data.candidates may be empty (not an error)