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 Errors and retries for the complete public problem catalog and resolution guidance. 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.

Idempotent request

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.

Problem response

{
  "type": "https://docs.swipelux.com/errors/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. See Errors and retries for every public code, stable problem type URI, retry behavior, and next action.

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

Versioning

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