AUO exposes the same data and logic over three surfaces. You use one account and one bearer token across all of them.

REST

The primary surface. Synchronous JSON over HTTPS for resolve, screen, validate, and watch management.

MCP

A Model Context Protocol server so an AI agent can call AUO as a set of tools, behind the same bearer token.

Webhooks

Outbound, signed notifications when a watched entity changes. The one surface that is inbound to you.

​
REST

Every endpoint lives under https://api.auo.com.au/v1 and requires Authorization: Bearer auo_sk_{test|live}_.... Requests and responses are JSON. This is where you resolve, screen, validate, and manage watch subscriptions. Start with the API reference.

​
MCP

The MCP server at https://api.auo.com.au/mcp lets an AI agent call AUO as tools. It is stateless, read-only by design, and uses the same bearer token as REST. Because each MCP tool calls the exact same core function as its REST counterpart, the two surfaces cannot drift.

​
Webhooks

Webhooks are the exception to bearer auth: they are inbound to your server, so they are signed with HMAC-SHA256 rather than carrying your token. You subscribe to an entity with the watch endpoints, and AUO POSTs a signed event to your URL when something changes. See Watch and webhooks for signature verification and the event taxonomy.

​
One token, one source of truth

The same resolve logic backs the REST endpoint, the MCP resolve_entity tool, and the change detection that fires webhooks. Add a red-flag source to one and it appears in all three. You never have to reconcile three different views of an entity.

​
Next

Watch and webhooks

Subscribe to an entity and verify signed events.

MCP

Connect an AI agent to AUO.