API reference

The API Reference is the authoritative contract for the Swipelux API. Each operation shows its request, response, security, status, and error schemas. Use https://platform.swipelux.com for every request. Send your environment-specific key in X-API-Key from a protected backend.

Make writes safe to retry

When an operation lists Idempotency-Key as required, generate one key for each intended operation and store it with your local request record.

curl --request POST \
  'https://platform.swipelux.com/v3/customers' \
  --header 'X-API-Key: YOUR_API_KEY' \
  --header 'Idempotency-Key: customer-order-1001' \
  --header 'Content-Type: application/json' \
  --data '{"type":"individual","externalId":"customer-order-1001"}'

If the response is uncertain, retry the identical method, path, and body with the same key. Do not reuse that key for a different operation or changed body. Some operations return Idempotency-Replayed: true when the response came from an earlier request with the same key. Treat that response as the result of the original operation, not as a second operation.

Handle errors

API errors use application/problem+json. Build client behavior around these stable fields:

Field	Use
`status`	HTTP status associated with the problem.
`code`	Stable machine-readable error code.
`detail`	Actionable explanation for the current request.
`retryable`	Whether retrying the same request may succeed, when present.
`errors[].pointer`	JSON Pointer to an invalid request field.
`correlationId`	Request identifier to retain in logs and support records.

The response correlationId mirrors X-Request-Id. Log both the operation and this value, but do not expose secrets or full financial details.

{
  "type": "https://docs.swipelux.com/problems/validation_error",
  "title": "Validation error",
  "status": 400,
  "code": "validation_error",
  "detail": "The request contains invalid fields.",
  "correlationId": "01JERRORVALIDATION",
  "errors": [
    {
      "pointer": "/externalId",
      "code": "invalid_format",
      "message": "Use a valid external identifier."
    }
  ]
}

Use the operation’s documented problem schemas to decide whether to correct input, refresh resource state, complete a task, or retry. Keep the full status and error catalog in the API Reference rather than hard-coding undocumented cases.

Track asynchronous operations

A successful create response starts many workflows; it does not guarantee completion. Store response-derived resource IDs, read the current resource, and use verified webhooks to react to changes. Start with POST /v3/customers, or follow the Quickstart for a complete sandbox journey.

Overview

Endpoints

Make writes safe to retry

Handle errors

Track asynchronous operations

​Make writes safe to retry

​Handle errors

​Track asynchronous operations

Make writes safe to retry

Handle errors

Track asynchronous operations