Authentication

Every call to the Reclack API is authenticated with an API key. The key also decides which environment you are talking to, so there is no separate sandbox host to remember.

An API key split into its Reclack prefix, its environment segment and its 32 random characters, above the Api-Key header it is sent in. — What a key is made of, and the headers it can travel in

Key format

Prefix	Environment	What it touches
`rk_sandbox_`	Sandbox	Test chains and test money. Nothing of value moves.
`rk_live_`	Live	Real networks, real stablecoins, real settlement.

A key is shown once, when it is created. We store only a digest of it, so we cannot show it to you again and a database dump yields nothing usable. If you lose a key, revoke it and mint another.

Sending the key

Send the key in the Api-Key header. This is what every example in these docs uses.

curl "https://api.reclack.com/v1/customers" \
  -H "Api-Key: rk_sandbox_your_key_here"

const response = await fetch("https://api.reclack.com/v1/customers", {
  headers: {
    "Api-Key": process.env.RECLACK_KEY,
  },
});

req, _ := http.NewRequest("GET", "https://api.reclack.com/v1/customers", nil)
req.Header.Set("Api-Key", os.Getenv("RECLACK_KEY"))

import os, requests

requests.get(
    "https://api.reclack.com/v1/customers",
    headers={"Api-Key": os.environ["RECLACK_KEY"]},
)

One other header works if your stack already puts credentials somewhere else:

X-API-Key: rk_live_your_key_here

We recognise a key by its own shape, so a session token sitting in the same header is never mistaken for one.

What a key can do

Keys carry permissions. A key that only records usage does not need the ability to create subscriptions, and giving it that ability is how a small mistake becomes a large one.

Permission	Covers
`products:read`, `products:write`	Catalog products and prices.
`customers:read`, `customers:write`	Customer records.
`subscriptions:read`	Subscriptions and their periods.
`usage:write`	Recording metered usage.
`invoices:read`, `invoices:write`	Invoices, sending, reminders and charges.
`checkout:write`	Creating checkout sessions.
`payment_links:read`, `payment_links:write`	Payment links.
`webhooks:read`, `webhooks:write`	Endpoints, secrets and deliveries.

Set these when you create the key in the dashboard. A call made with a key that lacks the permission is refused with a permission_error, not a silent no-op.

Keeping a key safe

A secret key is a bearer credential. Anyone holding it can act as your workspace. Keep it on your server, never in client-side code, a mobile binary, or a public repository.

A few habits that cost nothing:

Use separate keys for separate jobs, so one can be revoked without taking the rest of your integration down.
Rotate on a schedule, and immediately when somebody who had access leaves.
Keep sandbox and live keys in different places. The prefix makes a mistake obvious in a log line, which is exactly when you want to notice.
Never log the key. Reclack does not log secrets, and your service should not either.

Revoking a key

Delete it in the dashboard under Developers, then API keys, or call the API:

curl -X DELETE "https://api.reclack.com/v1/credentials/cred_7Fh2PqX9" \
  -H "Api-Key: $RECLACK_KEY"

Revocation takes effect on the next request. Calls already in flight finish.

Get started

Core objects

Taking payments

Recurring billing

Money and events

Key format

Sending the key

What a key can do

Keeping a key safe

Revoking a key

​Key format

​Sending the key

​What a key can do

​Keeping a key safe

​Revoking a key

Key format

Sending the key

What a key can do

Keeping a key safe

Revoking a key