Draft API Compliance Assets

Exploratory work on rules as code for the NZ API Guidelines and Standard

Status: Draft / Unvalidated Prototypes

What this is

This page documents exploratory work on creating automated compliance assets for the NZ API Guidelines and Standard. The work demonstrates that creating digital implementation assets from natural language standards documents is completely possible.

This is an example of rules as code and digital regulatory infrastructure—converting natural language requirements into computational form so that compliance can be checked automatically rather than manually.

What we explored

The NZ API Standard contains approximately 135 specific requirements across four source documents. Manually checking API compliance against these requirements is time-consuming, error-prone, and inconsistent.

We prototyped a system that:

• Extracts requirements from the natural language standard into a structured registry
• Validates OpenAPI specifications automatically against those requirements
• Generates tailored checklists based on API characteristics (type, exposure level, lifecycle phase)
• Provides test specifications for requirements that can't be validated from specs alone
• Maintains traceability via DocRef citations linking every rule back to its authoritative source

The prototypes cover tools including an OpenAPI validator (42 rules), checklist generator, security decision matrix, test specifications (36 tests), gateway policy templates, and compliance tracking schemas.

Current status

These are unvalidated prototypes. While the work produced useful outputs, significant effort would be required to verify and validate them against the Guidelines/Standard.

Key considerations:

• The NZ API Standard itself is still being finalised—it's a moving target
• Testing the assets on real-world APIs requires agency cooperation
• We're exploring how appropriate it is to publish draft materials to the transparency site

The materials here are published for transparency about the work undertaken, not as ready-to-use tools.

Next steps

We suggest dedicated work in the new year, with cooperation from specific agencies, to test the assets on real-world APIs. This hasn't been possible while the standard is still in flux.

When the standard stabilises:

• Validate the extracted requirements against the final standard
• Test the OpenAPI validator against production API specifications
• Refine the assets based on real-world feedback
• Consider formal publication of validated tools

Related work

• API Catalogue — Related work on cataloguing government APIs, using the same source standards
• Rules as Code and Digital Regulatory Infrastructure — Conceptual background on this approach

Transparency materials

December 2025