Skip to main content
Keep every Swipelux API key on a protected backend. Never place a key in browser code, a mobile application bundle, or a client-visible configuration file.

​
Send your API key

Use the shared base URL https://platform.swipelux.com and send your key in the X-API-Key header.
Verify your API key
GET /v3/capabilities confirms that the key is valid and your backend can reach the API.

​
Sandbox and production

Sandbox and production use the same API host. The API key selects the environment. Keep the environment choice in deployment configuration. A production deployment must never fall back to a sandbox key, and a sandbox deployment must never receive production credentials.

​
Key scope

Each API key works with customers and their accounts in its own environment and developer space. On customer routes, a customer outside that scope returns 404 customer_not_found. On quotes, an out-of-scope customer or source returns 404 not_found. A sandbox key cannot move live funds: a quote that names a live account or destination returns 404 not_found, as an unknown ID does. A wallet-move quote returns 404 not_found with Destination was not found. when the destination account belongs to another merchant or, for a sandbox key, is a live account. Store resource IDs alongside the environment and space that created them. Use the matching key for every later request on those resources.

​
Store credentials safely

Store sandbox and production keys in separate secret-manager entries. Grant each backend deployment access only to the entry it needs. Keep keys out of source control, logs, analytics, support screenshots, and error responses. Rotate a key if you believe it has been exposed. If a request returns unauthorized or forbidden, use Errors and retries to distinguish invalid credentials from missing permissions. Next, configure sandbox testing or start the Quickstart.