Swipelux

Authentication

Authenticate Swipelux API requests with server-side credentials.

Authenticate each Swipelux API request with a server-side credential. Most integrations send either a static secret API key or a short-lived API access token in the X-API-Key header. Keep credentials on your server and out of browser code, mobile apps, screenshots, and public repositories.

Static API Keys

Static keys created in the dashboard are environment-scoped, for example sk.live.* or sk.sbx.*. The full key is shown only once when it is created, so store it in your backend secrets manager before leaving the screen.

curl https://platform.swipelux.com/v1/customers \
  --request GET \
  --header 'X-API-Key: YOUR_SECRET_TOKEN'

Short-lived API Tokens

Some dashboard credentials include a token endpoint. When you create one, store the credential values and first access token in your backend secrets manager. Access tokens are short-lived, so request a fresh token before calling the API.

curl "$SWIPELUX_API_TOKEN_URL" \
  --request POST \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=client_credentials' \
  --data-urlencode "client_id=$SWIPELUX_API_CLIENT_ID" \
  --data-urlencode "client_secret=$SWIPELUX_API_CLIENT_SECRET"

Send the returned access token on Swipelux API requests. X-API-Key works for public API requests; endpoints that document bearer authentication can also accept the same access token in the Authorization: Bearer header.

curl https://platform.swipelux.com/v1/customers \
  --request GET \
  --header "X-API-Key: $SWIPELUX_API_ACCESS_TOKEN"

API Key Permissions

Dashboard-created static keys and token credentials can be scoped to specific API permissions. Select the permissions your backend needs when you create the credential. Existing legacy static keys and unscoped credentials keep full access for their environment.

If a scoped key or token calls an endpoint without the required permission, the API returns 403 with a message like API key is missing required permission: payins:write.

AreaPermission labels
Customerscustomers:read, customers:write, customers:delete
Wallets and balanceswallets:read, wallets:write, wallets:delete, balances:read
Accounts and railsaccounts:read, accounts:write, accounts:delete, rails:read, rails:write
Documents and KYBdocuments:read, documents:write, documents:delete, kyb:read, kyb:write
Recipientsrecipients:read, recipients:write, recipients:delete
Pay-inspayins:read, payins:write, payins:quote
Payoutspayouts:read, payouts:write, payouts:quote
Transferstransfers:read, transfers:write
Platformwebhooks:read, webhooks:write, rates:read, spec:read, merchant-settings:read, merchant-settings:write

Older credentials or internal tools may still show wi:-prefixed permission claims. Swipelux accepts those legacy claims for compatibility, but new keys and access tokens should use the unprefixed labels above.

The dashboard may show additional test-environment utility permissions for non-production tools.

Server-side Boundary

Use https://platform.swipelux.com for every public example in these docs.

For exact authentication behavior, open the API reference.

On this page