> ## Documentation Index
> Fetch the complete documentation index at: https://docs.swipelux.com/llms.txt
> Use this file to discover all available pages before exploring further.

# API reference

> Use the API contract, retry writes safely, and handle errors consistently.

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.

```bash theme={null}
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.

```json theme={null}
{
  "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](/integration/webhooks) to react to changes.

Start with [`POST /v3/customers`](/api-reference/customers/post-v3-customers), or follow the [Quickstart](/integration/quickstart) for a complete sandbox journey.


## Related topics

- [Individual onboarding API workflow](/knowledge-base/individual-onboarding/api-workflow.md)
- [Account created](/api-reference/webhooks/account-created.md)
- [Capability created](/api-reference/webhooks/capability-created.md)
- [Customer archived](/api-reference/webhooks/customer-archived.md)
- [Customer created](/api-reference/webhooks/customer-created.md)