checklist

API Audit Checklist

A lifecycle-based checklist to verify API readiness across design, delivery, publishing, and compliance using defined audit criteria and evidence.

Outcomes

  • Shared understanding of the purpose and use of API Audit Checklist
  • A consistent approach to applying API Audit Checklist
  • Improved application of the related practices

How it works

  1. Use the API Audit Checklist to ensure the API design meets functional and non-functional requirements, including security, performance, and compliance.
  2. Conduct audits to assess lifecycle coverage and verify that the API meets business, design, and operational standards.
  3. Ensure that documentation, security models, gateway configuration, and legal requirements are clearly defined, validated, and supported by evidence.

Source content

Strategy

Strategy is Ready When...

  • API is based on clear business needs
  • All concept checklist items are audited

Architecture

Architecture is Ready When...

  • Versioning strategy decided and supported by gateway
  • Only accessible via API gateway
  • Rate limits are enforced

Design

Design is Ready When...

  • Endpoints have business value and feature descriptions
  • API hides raw backend data and is designed for shared use
  • API design is consistent with other APIs
  • Data and attribute naming uses descriptive English
  • Mandatory fields are specified
  • Dates use ISO format with timezone
  • General data uses standard values
  • Field names avoid acronyms and use full words
  • Creating new resources returns identifiers
  • Endpoint paths contain max two resources or sub-resources
  • Endpoints and attributes include examples
  • POST is used for create or update
  • DELETE is used to remove resources
  • GET has no request body and returns content
  • GET returns 204 if response body is empty
  • POST returns 200 OK when updating
  • POST returns 201 Created with ID on create
  • DELETE returns 204 on success
  • 400 errors provide specific error information
  • 401 Unauthorized for wrong credentials
  • 403 Forbidden for unauthorized operations
  • Spec contains request and response schema
  • UUIDs or pseudo-identifiers instead of DB IDs
  • No sensitive data in URLs
  • HTTP methods only for intended resources

Delivery

Delivery is Ready When...

  • All prototype and design items are audited
  • Spec validated on every change
  • Schema and examples pass validation
  • Uses HTTPS or encrypted protocols
  • Endpoints protected by authentication
  • Token-based authentication
  • Protected against CSRF
  • Inputs auto-validated by framework
  • Outputs auto-escaped by framework
  • Encryption for data in transit and storage
  • Message integrity implemented

Publishing

Publishing is Ready When...

  • Published via API management
  • Visible in developer portal
  • Docs auto-generated from spec and schema
  • Spec auto-updated to gateway and dev portal
  • Published under official organization domain

Improving

Improving is Ready When...

    Related stations