Requests and responses
Nozle APIs use JSON request and response bodies. Send:Z. For Cost Events and credit usage the broader forms are available from the Engine release that includes this change; before it, credit usage takes RFC 3339 only and Cost Events take a number only. A date without a time and a time without an offset are rejected everywhere. Monetary amounts use integer minor units, such as cents, unless an endpoint explicitly documents a decimal string.
Pagination
Collection endpoints usepage and per_page query parameters. Paginated responses include metadata with the current page, adjacent pages, total pages, and total record count.
External identifiers
Prefer stable external identifiers from your own system when an endpoint accepts them. They make reconciliation easier and prevent your application from depending on database-generated UUIDs.Idempotency and retries
For metered events and credit operations, generate a unique transaction or idempotency identifier and reuse it when retrying the same logical operation. Do not generate a new identifier after a timeout unless you intend to create a second operation. Retry transient network failures and HTTP429 or 5xx responses with exponential backoff and jitter. Do not automatically retry validation or authorization failures.
The Node.js, Python, and Go SDKs do not retry unless you turn it on (maxRetries, max_retries, WithMaxRetries); the setting retries only requests that are safe to repeat. To retry in your own code, do it only after a network error, a 429, or a 5xx, and send the same idempotency key with the same request, including its timestamp.
Errors
Use the HTTP status code as the primary error category and log the response body for diagnosis. Common statuses include:
See Errors for retry guidance and application-safe handling.
Compatibility names
Some inherited response properties and webhook headers retain compatibility names from the underlying billing contract. Use the exact names displayed in the generated endpoint schemas. Those names can change, and a change is announced in the changelog first.Legacy key names (removal January 19, 2027)
API 1.0.0 renamed the identifier keys of REST responses, webhook payloads and CSV exports and the EU tax codes, from the former product prefix tonozle_ (nozle_id) or to no prefix (customer_id, plan_id), without notice. Until January 19, 2027 (inclusive) the old names work again next to the new ones. After that date they are removed.
- Responses and webhook payloads carry the old key beside the new one, with the same value, on every object that had it before: the old id key beside
nozle_id, and the old prefixed key beside each of these keys:add_on_id,alert_id,charge_filter_id,charge_id,coupon_id,credit_note_id,customer_id,feature_id,fee_id,fixed_charge_id,integration_id,invoice_id,invoice_ids,item_id,order_form_id,organization_id,original_fee_id,parent_id,payable_id,payment_provider_id,payment_request_id,plan_id,pricing_unit_id,quote_id,quote_version_id,subscription_id,tax_id,true_up_fee_id,true_up_parent_fee_id,user_id,voided_invoice_id,wallet_id,wallet_transaction_id. A key gets its old name only on the objects where it was renamed. - EU tax codes: an old EU code resolves to the matching
nozle_eu_code in everytax_codesinput and inGET,PUTandDELETE /taxes/{code}: the oldfr_standardcode resolves tonozle_eu_fr_standard. A tax you created yourself with an old EU code keeps that code. Responses show thenozle_eu_code. - CSV exports (invoices, invoice fees, credit notes, credit note items) repeat the id columns at the end under their old names (the old
idcolumn and the oldcustomer_,invoice_,fee_,credit_note_,credit_note_item_andcredit_note_item_fee_id columns). The earlier columns are unchanged. - The old webhook header names stay as before.
nozle-openapi.yaml).
Migrate before January 19, 2027: read nozle_id and the new key names in your webhook receivers, API clients and CSV imports (by column name), and use the nozle_eu_ tax codes. The new names are always present. Event properties you send are never changed.