All AUO API calls (REST and MCP) use a single bearer token per account. Pass it in the Authorization header on every request. 
Authorization: Bearer auo_sk_live_your_key_here

​
Test tokens vs live tokens

Every account gets two token prefixes. The prefix determines which data is returned. The code path is identical.

auo_sk_test_...

Returns synthetic sandbox fixtures. Free, no card required. Safe to use in development, CI, and demos. Quota does not count against your plan.

auo_sk_live_...

Returns real government data from the ABR, ASIC, ACNC, GLEIF, and the other joined sources. Counts against your plan allowance.
The test sandbox returns realistic fixture responses that exercise every response shape, including screening review hits and empty candidates. Use it to build and test integrations before switching to a live key.

​
Getting a key

Sign up at auo.com.au/app/signup (no credit card for the sandbox). Go to the dashboard keys page and click Create key. The plaintext key is shown once, at creation only. Copy it immediately and store it in a secrets manager or environment variable. There is no “view key” option. If you lose the key, roll it (see below).

​
Key security

  • Never put a key in a URL or query string. URLs appear in server logs and browser history. Always pass the key in the Authorization header.
  • Never commit a key to source control. Use environment variables or a secrets manager.
  • Keys are hashed at rest. AUO stores only a SHA-256 hash of each key. We never see your plaintext key after creation, and it cannot be retrieved from our end.

​
Rolling a key

If a key is compromised or lost, roll it from the dashboard keys page. Rolling regenerates both the bearer token and the webhook signing secret together. Both are invalidated and replaced in a single operation.
Rolling a key immediately invalidates the old token and the old webhook secret. Update both in your systems before rolling in production.

​
What a 401 looks like

A missing or invalid bearer token returns a 401 with this shape: 
{
  "error": {
    "type": "unauthorized",
    "message": "Invalid or missing bearer token.",
    "request_id": "req_01abc..."
  }
}
See Error handling for the full error reference.

​
Webhooks are the exception

Webhooks are inbound to you (AUO posts to your endpoint), so they use a different authentication model: HMAC-SHA256 signature verification. Every webhook POST includes two headers:
  • X-AUO-Signature: t={unixTs},v1={hex} where hex is the HMAC-SHA256 of the string "{t}.{body}" (the Unix timestamp, a dot, then the raw request body).
  • X-AUO-Event-Id: a unique identifier per event, stable across retries.
To verify a webhook:
  1. Extract t and v1 from X-AUO-Signature.
  2. Compute HMAC-SHA256(secret, "{t}.{body}") using your subscription’s signing secret.
  3. Compare the result to v1 (constant-time comparison).
  4. Reject the request if t is more than a few minutes in the past (replay protection).
The signing secret is shown once when you create a watch subscription. Rolling a key also rotates the signing secret. See Watch and webhooks for the full guide.

​
Next steps

Quickstart

Make your first authenticated API call.

Pricing

Sandbox is free. See the plan tiers and what counts toward the allowance.