Skip to main content
Complete reference for all Ozura Checkout API endpoints.

Base URL

Environments: Use https://checkout.ozura.com for production. For staging, use the URL provided by your Ozura representative.

Authentication

All requests require these headers:

Rate Limits

Rate limits are applied per API key to ensure fair usage. If you exceed rate limits, you’ll receive a 429 Too Many Requests response.

Create Session

Creates a checkout session and returns a checkout URL.

Request Body

*amount is required when checkoutMode is "payment" or "recurring" and items is not provided. Not required for "donation" mode.
Deprecated fields: taxRate and shippingCost are accepted and validated but ignored — they have no effect on pricing. Do not send these fields in new integrations.

Response

The response may also include a top-level "warnings" array with advisory messages. On an idempotent replay (same idempotencyKey), "cached": true is added at the top level and a new session is not created.

Get Session

Retrieve session details. The session ID acts as the access token — no additional authentication headers are required.

Response

The full session object is returned. Key fields include:
merchantName is stored inside metadata, not as a top-level session field. For recurring sessions, recurringConfig contains the full plan config object. The metadata object may contain internal fields used by the checkout page — do not expose, log, or forward the full metadata object to clients.

Session Statuses

Cancel Session

Cancels a pending session. This endpoint is called automatically by the Ozura checkout page when the customer clicks “Cancel” — you do not need to call it from your server.
This endpoint is browser-facing. It is called by the checkout page using a short-lived internal session credential. It cannot be called from your server using your Vault API Key — requests with X-API-KEY are rejected. If a session is not cancelled explicitly, it expires automatically after 30 minutes.

Response

Creates a reusable payment URL.

Request Body

*Required when checkoutMode is "payment" or "recurring" and items is not provided. Not required for donation mode.
Correlating payments to your orders. Payment links support three correlation references, all returned in the success-redirect metadata (see Correlate Payments to Your Orders for the full guide):
  • merchantPayLinkReference — set here at link creation; static, returned on every transaction from the link (attribute a link/campaign).
  • merchantReference — set per checkout via a ?ref= query parameter appended to the link URL (not a request-body field); unique per payer.
  • merchantRecurringReference — for recurring links, set inside recurringConfig; also persisted on the plan so you can look the plan up by it.

Response

On an idempotent replay (same idempotencyKey), the response also includes "cached": true. Either response may include a top-level "warnings" array with merchant-facing advisory messages. Check if a payment link is still valid. No authentication required.

Response (Available)

Response (Unavailable)

Error Responses

All errors follow this format:
details is only included when there are multiple specific validation failures (e.g. several invalid fields at once). Single-field and non-validation errors return error only.

Common Error Codes

Idempotency Conflict Codes

When you replay a request with an idempotencyKey that does not match the original active session, the API returns 409 with one of these machine-readable errorCode values: