OpenAPI Spec

This document covers the machine-readable description of the API that the Platform publishes to approved accounts: how to obtain it, what it contains, how to use it to generate a client, and how it relates to this written reference (Overview through Request and Response Examples).

Obtaining the description

The description is an OpenAPI 3 document in JSON, covering every endpoint, request body, response shape, and error response in this reference (API Reference). It is provided to approved accounts by either route

• Download it from the Developer section of the Seller Center, where the current document is posted whenever the API changes.
• Request it from support@aapawz.com, and the current document will be sent to your account's technical contact.

The document is not posted publicly, and it describes only the endpoints your tier may use: a description issued to an import-tier account contains the import surface, not program endpoints outside that tier (Authentication Endpoints). Treat the document as you treat your key: it is issued to your account, and it is not for redistribution.

Each issued document carries a publication date and a document version. Keep the copy you generated your client from, so a later difference can be traced to a dated change in the Changelog.

What it contains

• Every path and method in this reference, with the parameters, request bodies, and response bodies as specified in the endpoint documents.
• The shared definitions: the error body (Error Codes), the page shape (Pagination and Filtering (Pagination & Filtering)), money, timestamp, and identifier formats, and the enum values from Data Types and Enums.
• The authentication requirement on each operation: the bearer key scheme from Authentication Endpoints.
• The webhook event payloads from Webhook Event Schemas, described as callback payloads, so event handling can be typed alongside request handling.

Generating a client

Any standard OpenAPI client generator can turn the document into a typed client in your language

1. Generate the client from the issued document, with the base URL set to https://www.aapawz.com/api.
2. Configure the generated client to send your key as Authorization: Bearer <your-api-key> on every request. Never bake the key into generated code that is committed to a code host; inject it from your secrets configuration at run time.
3. Wrap the generated calls with your retry policy: honor the rate-limit headers, and send an Idempotency-Key header on writes (see Idempotency Keys): generators do not add it for you.
4. Regenerate when a new document is issued, and review the differences before deploying: additive differences (new endpoints, new optional fields) are safe to adopt at leisure; a changed or removed element will be announced in advance in the Changelog with the date it takes effect.

Validate a generated client's calls against the worked examples in Request and Response Examples before pointing it at production data.

When the documents differ

This written reference prevails over the machine-readable description on any conflict. The description is a convenience for tooling; the endpoint documents in API Reference state the contract, including the rules a machine description cannot express: validation behavior, status transitions, and business rules such as refund balances and authorization validity. If you find a conflict, build to this reference, and report the difference to support@aapawz.com so the description can be corrected.

Enum values deserve one caution: the description lists them as of its issue date. The controlling list is Data Types and Enums; write clients that tolerate a new value gracefully, as that document directs.