Getting started

Authentication.

Your server authenticates with a merchant API key. The dashboard uses a separate login session. Two callers, two mechanisms.

API keys

Send your key as a bearer token on every request:

http

GET /v1/payments/<paymentId> HTTP/1.1
Host: axle-production-fa2b.up.railway.app
Authorization: Bearer sk_test_...

Property	Detail
Format	`sk_test_…` or `sk_live_…`. The header must start with `Bearer sk_`.
Scope	One key belongs to one merchant and can only see that merchant's data.
Environment	A key is either `test` or `live`. Objects you read back carry a matching `livemode` flag.
Storage	Shown in full exactly once, at creation. Axle stores only a hash, so a lost key can't be recovered, only rotated or revoked.
Where to manage	The merchant's API Keys tab in the dashboard: create, rotate, revoke.

What an API key can call

Endpoint	Purpose
`GET /v1/payments/:id`	Read one payment.
`POST /v1/payments/:id/refunds`	Start a refund (requires an Idempotency-Key).
`GET /v1/refunds/:id`	Read a refund.
`GET /v1/events`	Poll events, the fallback if you can't receive webhooks.
`POST /v1/payment-links`	Create a fixed-amount payment link, for example one per store order.
`GET /v1/payment-links/:id`	Read a payment link.
`POST /v1/payment-links/:id/deactivate`	Close a payment link.
`POST /v1/payments/:id/disputes`	Disputes sandbox.

Limiting what a key can do

When you create a key you choose its access. A key that can only do what its integration needs is much less harmful if it ever leaks. Calling something outside a key's access returns 403 insufficient_scope.

Scope	Allows
`*`	Everything below. Every key created before scopes existed has this.
`payments:read`	Reading payments, refunds, payment links, disputes and events.
`payment_links:write`	Creating and deactivating payment links.
`refunds:write`	Starting refunds.
`disputes:write`	Opening disputes and submitting evidence (sandbox).

The dashboard offers three presets: Full access, Store plugin (payments:read and payment_links:write) and Read only. Rotating a key keeps its access.

Authentication errors

Status	code	Cause
401	`missing_api_key`	No `Authorization` header, or it doesn't start with `Bearer sk_`.
401	`invalid_api_key`	The key doesn't exist, or it has been revoked.

Dashboard sessions

The dashboard signs in with email and password and holds a short-lived access token plus an httpOnly refresh cookie. Endpoints under /v1/merchants/… (payment links, invoices, subscriptions, webhook endpoints, analytics, customers) use that session. They're how the dashboard works, not a server-to-server API, which is why this documentation doesn't treat them as an integration surface.

Sign-in is rate limited to 5 attempts per minute.
MFA (TOTP) is supported on dashboard accounts.

PreviousQuickstart Next Payment links & checkout