Getting an API key
An API key is what lets your backend call the TEDR Pay API without a dashboard session. The first key is issued in the dashboard — there is no endpoint that hands you one before you have signed in. This guide walks the three screens involved: creating the account, finding the API keys tab, and generating the key itself.
What the fields mean, what rotating and revoking do, and the endpoints that manage a key afterwards are on the API keys reference. Signing your requests with the key is covered on Authentication.
Sign up
Registration is a single screen, /sign-up, titled Create an account.
- Fill in Email, Password and Repeat password, accept the Terms & Conditions checkbox and press Continue.
- A Confirm email dialog opens and asks for the 6-digit code sent to that address. The hint on it points at your spam folder if the code does not arrive.
- Entering the correct code both confirms the address and signs you in — there is no separate login step and no further profile form.
API keys
Keys live under Settings, on the API keys tab (/settings/api-keys). The card is titled API Keys and carries an API documentation link, which opens the API keys reference.
Before you have a key the card shows No API keys here yet with a single Generate button. Once a key exists, the card shows it as one table row with the columns ID, Name, Public key, Created at and Webhook URL. The chevron at the end of the row (View API key) opens an API key dialog with the same values and a Delete button. In the table row only Public key and a non-empty Webhook URL carry a copy button. In the dialog every row carries one except Created at.
One active key at a time.
The Generate button appears only while you have no key, and the API enforces the same limit: asking for a second key while one is active is refused. Replacing key material is a rotation rather than a delete-and-create — see API keys.
The dashboard labels and the API field names do not line up one-for-one. What you read on screen maps like this:
| Dashboard label | API field | Shown |
|---|---|---|
| ID | id | Always |
| Name | name | Always |
| Public key | privateKey | Always |
| Secret key | secretKey | Only in the dialog right after you create the key |
| Webhook secret | webhookSecret | Only in the dialog right after you create the key |
| Webhook URL | webhookUrl | Always |
| Created at | createdAt | Always |
"Public key" is the privateKey field.
The value shown under Public key is what API responses call privateKey and what you send in the KeyId header. It identifies the key and is not a secret. The secret that signs requests is secretKey, shown as Secret key.
Generate a key
Generate opens its own page, /settings/api-keys/generate, headed Generate API Key. It has two fields:
- Key name — required, a label you choose.
- Webhook URL — optional. Leave it empty and the key is created without one.
Save creates the key and opens an API key dialog listing ID, Name, Public key, Secret key, Webhook secret and Webhook URL — the four key values carry a copy button, ID and Name do not — above the notice Please copy your Secret Key and Webhook Secret now. For security reasons, they will not be shown again.
The two secrets are shown exactly once, in this dialog.
Copy Secret key and Webhook secret into your own secret storage before you leave. The dialog closes only through I saved it — Escape and a click outside are ignored on purpose, so the values cannot disappear by accident. Neither the table nor the API key dialog you open later shows them again, and no endpoint reads them back.
Changing the webhook address afterwards does not go through this screen: the dashboard displays Webhook URL but does not edit it. Use the update endpoint on the API keys reference — it changes the address and leaves privateKey, secretKey and webhookSecret as they are, so a running integration keeps working.
Deleting is the blunt option. Delete in the API key dialog raises a Warning confirmation that spells the consequence out: All active integrations using this key will stop working immediately. That is accurate for requests: a revoked key authenticates nothing from the moment it is revoked, and there is no grace period. It is a soft delete on our side, though, not an erasure — invoices created while the key was live keep being notified, signed with the webhook secret they were created under, so an endpoint of yours can still receive them afterwards. See Webhooks.
Replacing key material is a rotation, not a delete.
Because only one key can be active, you cannot create the replacement first and retire the old one afterwards — and deleting first leaves your integration unauthenticated in between. Rotating is the way out: one call replaces privateKey, secretKey and webhookSecret together, while id, name, webhookUrl and createdAt stay as they were.
privateKey is in that first list, so the KeyId header changes too: deploy the whole new set at once, not just the secret, or every signed request answers 401. The new material takes effect immediately, so there is still a window — plan the rotation, do not improvise it. The call is on API keys.