Building AUO: a developer-first API for Australian business data

What’s your background, and what does AUO do in a sentence or two?

I’m a web developer who has spent years working with small and medium-sized businesses across Australia. That work gave me a close view of how often businesses need reliable company information: for onboarding, billing, compliance, CRM hygiene, and simple operational checks.

AUO is an Australian business-data API that lets developers resolve and verify an entity using an ABN, ACN, or company name. It brings fragmented free public-register data together into a single verified record, with REST API access, an MCP server for AI agents, and webhooks for ongoing monitoring.

What’s the backstory, and how did you know people actually wanted it?

The idea came from trying to combine ASIC and ABN data in a reliable way. Australian business information is available publicly, but it is fragmented across multiple government websites, APIs, file formats, and data sources. What should be a straightforward question (“is this business real, active, and who do the public registers say it is?”) quickly becomes a data-integration problem.

The moment it clicked was realising that the underlying issue was not a lack of data; it was the effort required to collect, normalise, reconcile, and keep it current. Developers should not need to build and maintain a pipeline around SOAP/XML services, CSV dumps, inconsistent specifications, and separate screening sources just to verify a business.

The demand signal was also clear. Unified APIs and API gateways already existed, but many were either difficult to use, unreliable, or priced beyond the reach of smaller teams. I saw room for a developer-first alternative: transparent coverage, clear limitations, usable documentation, and public pricing.

What went into building and launching the first version?

I built AUO solo and bootstrapped it from the beginning. The first version took roughly a month to build and launched as a simple lookup API focused on resolving Australian entities.

The initial goal was deliberately narrow: make it easy to look up an ABN, ACN, or company name and return a useful, consistent response. From there, the product expanded into a unified data layer that combines 18 free government registers and supports business verification, sanctions and banned-register screening, and change monitoring.

The difficult part was less about building an API endpoint and more about making inconsistent public data usable. Every source has its own formats, update schedules, definitions, specifications, and edge cases. Some are APIs, some are published files, and some require working with spreadsheet-style data. A large part of the work has been normalising those sources without hiding their provenance or overstating what the public record can prove.

How did the first developers find you?

The main acquisition channels have been SEO and public documentation.

This is a product developers often discover when they are already trying to solve a specific problem: ABN validation, ACN lookup, KYB onboarding, sanctions screening, or Australian business-data enrichment. Clear technical documentation and pages built around those real integration needs have been important.

I wanted someone to be able to find AUO, understand exactly what it covers, get a sandbox key, and test a real integration without needing a sales call.

What’s the model, and how did you decide?

AUO is a cloud API product with a free sandbox and paid usage tiers for live data. The same account and bearer token work across REST, the MCP server, and webhooks.

That model followed directly from the problem. The complexity belongs in the data layer, not in every customer’s application. Rather than asking teams to self-host, collect, clean, reconcile, and monitor dozens of sources themselves, AUO exposes one consistent interface that they can use in their existing systems.

The free sandbox was important because developers should be able to build and validate an integration before making a purchasing decision. The paid plans then support live data access and monitoring at different usage levels.

What is one thing about the developer experience you obsess over?

The main thing I obsess over is honesty in the response.

Australian public-register data has real limits, and it is easy for a data provider to make a result sound more definitive than it is. AUO is designed to show where a field came from, when it was read, and where information conflicts or is incomplete. A sanctions result, for example, is a possible match or no match, not a claim that an entity has been “cleared.”

I also care about reducing integration friction. Developers should not need to learn a different interface for lookup, AI-agent use, and monitoring. That is why AUO supports REST, MCP, and signed webhooks as complementary surfaces rather than separate products.

I keep the implementation details of the internal stack private, but the product architecture is built around normalising diverse government data sources into a consistent, source-attributed API response.

Where are you today?

I’m keeping customer and revenue figures private for now.

The milestone I’m most proud of is building AUO as a unified platform rather than just another lookup endpoint. Developers can access the same underlying entity data through a REST API, an MCP server for AI agents, and signed webhooks for monitoring changes over time.

That combination matters because business verification is rarely a one-off lookup. Teams need to resolve an entity at onboarding, screen it against relevant public lists, and be notified when something important changes later.

What were the biggest challenges or mistakes so far, and what would you do differently?

The biggest challenge has been the source data itself. Public information is distributed across many systems with different technical specifications, formats, publishing cycles, and assumptions. Some sources behave like conventional APIs; others are CSV or Excel-style datasets; others require more careful interpretation.

A key lesson has been that the technical challenge is only half the job. The other half is communicating data limits clearly. It is important not to imply that free public records can answer questions they cannot, for example around directors, shareholders, beneficial ownership, or whether a screening result constitutes a formal clearance.

If I were starting again, I would invest even earlier in source-by-source data modelling and edge-case handling. The product looks simple from the outside (one request in, one business record out) but earning trust requires a lot of work beneath that interface.

What’s your advice for founders, and what’s next for AUO?

My advice is to begin with a painful, specific problem you understand firsthand. In AUO’s case, the problem was not abstract: developers and businesses were spending too much time stitching together fragmented Australian business-data sources.

Start narrow, make the first useful version available quickly, and focus on whether it actually removes work for a real user. You do not need to solve every adjacent problem on day one. Build trust through clarity, documentation, and a product that does what it says.

For AUO, the focus is continuing to make Australian business verification and monitoring easier for developers and teams that need it. That means improving the reliability and usability of the unified data layer while maintaining a clear, honest view of what the public record does, and does not, contain.

You can find AUO at auo.com.au.