Audits

An audit is the act of looking systematically at what actually happened — who accessed what, when, under what authorization, and whether the system behaved the way it was supposed to. In the API world, auditing is the discipline that turns the invisible flows of data and access into something reviewable, accountable, and ultimately governable. I treat auditing as a political question as much as a technical one, because the most important thing about an audit is not the mechanics of reading logs — it’s who has the right to perform the audit, what they’re allowed to see, and whether the powerful are actually subject to it. An audit nobody outside the platform can ever run is not accountability; it’s theater.

Everything in auditing rests on one foundation: logging. I’ve argued for years that log files are treated as an afterthought — something you only look at when things go wrong — when they should be treated as first-class data infrastructure. Every API call leaves a record, and that record is the raw material of every audit you might ever want to perform: security, usage, compliance, billing, forensics. If you don’t capture comprehensive access logs, you have nothing to audit later, and no way to reconstruct who did what. The access log is the ground truth. I’ve connected API logging to other layers in practice — wiring Apache logs into DNS security rules through the CloudFlare API so that traffic patterns in the logs drove real-time, proactive security responses. That’s auditing as a live operational loop, not just a retrospective review.

The distinction I keep coming back to is between observability and transparency, because it’s central to why auditing is political. You can be actively observing the outputs of your monitoring, testing, performance, and security operations — but if that data is locked inside one team and inaccessible to others in the company, to partners, to regulators, or to the public when required, then the system is not actually observable in any meaningful sense. Observability is the technical capability. Transparency is the political choice to make what you observe available to the people with a legitimate interest in auditing it. A platform can have perfect internal observability and zero accountability, because it never lets anyone else see. Auditing only becomes accountability when the audit trail is reachable by someone other than the party being audited.

The clearest case study for why third-party auditing matters is Cambridge Analytica. Facebook had an API management layer that could, in principle, see what every consuming application was doing — and it didn’t meaningfully audit them. I wrote in 2018 that if Aleksandr Kogan was holding that many OAuth tokens for Facebook users, Facebook should have been all over his operation, understanding what he was doing, where his money came from, and who his partners were. Once data leaves the nest through an API, you can’t trust that every developer has the platform’s or the end user’s interest in mind, and you have very little control after the fact — which is exactly why you need to audit consumers continuously while they have access, not discover the abuse years later. My proposal then, and still, is an auditable or regulatory layer where government agencies or third-party auditors can get access to the access logs for all applications, plus a community directory that forces transparency about who is consuming the API and what they’re doing with it.

That same auditable-layer idea applies directly to surveillance and power. I wrote in 2016 about transparency in police access to social platforms through OAuth and APIs, and the framework was the same: an auditable layer where other agencies or third-party auditors could reach the access logs for every application registered to law enforcement. I described it as something close to real-time FOIA access to the API management layer — a window into how law enforcement is actually searching and using social media data. Modern API infrastructure is genuinely good at this when it’s pointed in the right direction. You can give law enforcement the access they legitimately need while simultaneously making that access auditable by the public it serves. The technology to audit the watchers exists. Whether it gets deployed is a question of political will, not engineering.

Auditing algorithms is the same argument extended to automated decision-making. If an algorithm impacts your life — credit scoring, COMPAS risk assessment, predictive policing, content moderation — it should be opened up with an API for auditing. The API definition describes the algorithm’s input and output surface area, OAuth governs who can reach it, and logging records how the algorithm responds across a wide range of audit and test scenarios. That gives independent researchers and regulators a way to actually examine the system’s behavior instead of taking the operator’s word for it. I pointed to HunchLab as the model — open-source algorithms, disclosed input variables, models and training data shared with independent researchers — and noted that the transparent competitors in predictive policing were doing just fine commercially. The secret sauce was never the code; it was the training and support. The refusal to be audited is a choice, not a technical necessity.

Auditing also has to be turned inward, on your own operations, and this is where most organizations are quietly terrible. I wrote about bringing my own IT infrastructure out of the shadows — all the little scripts, the jobs I hadn’t run in months, the code exhaust from years of operation that lived unaccounted-for across my systems. The biggest security lapse in my world was simply things being unknown. Anything unaccounted-for lives in the shadows and is, by definition, a risk you can’t audit. The fix was an API-first approach: a single doorway, a single authentication approach, and a complete map of my surface area using OpenAPI and APIs.json, so I could actually audit, monitor, deprecate, and secure the whole thing. This is the shadow API problem at enterprise scale — the undocumented, undiscovered APIs that no inventory captures are exactly the ones no audit can cover. You cannot audit what you haven’t discovered, which is why discovery and inventory are the unglamorous precondition for any real audit program. When I tell organizations to inventory their operations before doing anything else — automation, clients, gateways, governance, logging, monitoring, observability, traceability, and the rest — it’s because the audit is only as complete as the map.

Specifications turned auditing into something you can automate. OpenAPI, JSON Schema, AsyncAPI, and APIs.json are audit artifacts — machine-readable descriptions you can check definitions against. Governance linting with tools like Spectral and Vacuum is auditing the contract itself: does this API definition meet the organization’s standards for descriptions, contacts, licensing, security definitions, response schemas, naming. That’s a quality and compliance audit that runs automatically on every definition, in the pipeline, before anything ships. And the event-driven world needs the same thing — I described the schema registry, like Amazon EventBridge’s, as needing deep traceability and auditability built in: the ability to understand where a message originated and every way it was used, and to audit an entire organization’s or team’s schema footprint. The schema registry becomes the audit surface for everything flowing through an event-driven enterprise.

There’s one more dimension I always insist on, which is auditing for misuse and for the incentives behind it. A weaponization audit doesn’t just check whether the technology can be abused — it asks how the business model itself incentivizes bad behavior, or rewards looking the other way. Harassment that drives engagement, data sharing that generates revenue: the most important audit findings are often not technical vulnerabilities but business-model misalignments where the platform profits from exactly the behavior an audit should flag. That’s why auditing is in the Politics book and not just the Technology one. The logs and schemas and linting rules are the instruments, but the real subject of an audit is power — who exercises it through the API, who is accountable for how it’s used, and who is permitted to look. An audit regime that only the platform controls audits nothing that matters. The work is building auditable layers that regulators, researchers, journalists, and the public can actually reach, so that observability finally becomes accountability.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

Audits

References

Guidance Details

Explore more

Discover APIs