Introduction

The TEDR Pay API issues crypto invoices on your behalf and tells you what has been paid against them. Your backend creates an invoice, hands the buyer the payment link that comes back, and reads the invoice and its payments to decide when the order is settled. Choosing a payment currency, quoting a rate and collecting the transfer all happen on the hosted payment page, so your integration never touches a wallet.

This reference covers the endpoints your backend calls and the dashboard steps that come before them. Start with the Quickstart if you want the shortest path to a working invoice.

Base URL and responses

Every path in this reference is written in full, relative to one base URL:

https://dev-app.tedr.com/api

Requests and responses are JSON. A successful call answers 200, 201 when it created something, or 204 with no body at all — revoking an API key is the one route that does. A failure answers the matching HTTP status and the same envelope every time — code is the stable identifier to branch on, message is the human-readable description of the same thing.

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Human-readable description of the failure"
  }
}

The full list of codes is on the Errors page; each endpoint repeats the ones that apply to it.

Two ways to authorize

Every route is authorized, and there are two kinds of caller. The dashboard signs in as a session and sends a JWT. Your own backend holds no session and signs each request with an HMAC built from an API key's secretKey.

Ways to authorize a request
Caller	Credential	Where it works
Dashboard session	The session JWT	Every route in this reference. It is the only option for the API key and withdrawal routes.
Your backend	An HMAC signature built from the API key	Invoices, transactions and `/merchants/me`. The route decides from the request itself: with a `KeyId` header present it checks the signature instead of the session — see Authentication.

A backend integration therefore lives inside the signature-accepting routes: it can create invoices, read them and their payments, run the invoice commands and read the transaction history. Issuing the API key itself and requesting a withdrawal stay in the dashboard.

Where to find what

The section is ordered the way an integration is usually built: get going, authorize, then the endpoint reference, then the dashboard side of the same objects.

Pages in this reference
Page	What it covers
Quickstart	Your first invoice end to end, from issuing a key to checking the payment.
Errors	The error envelope and every code the API returns, with the request behind each one.
Authentication	What gets signed, the four signature headers, and which routes accept a signature.
API keys	Create, read, update, rotate and revoke the key your backend signs with.
Webhooks	How webhook delivery is configured today, and why a callback is not proof of payment.
Invoices	Create, list and inspect invoices of all four types, and cancel, reactivate or delete them.
Transactions	The transaction history, one row per business event, with filters and search.
Withdrawals	Request a payout from your balance, confirm it by email and follow its status.
Getting an API key	The dashboard path to a key, and the two secrets you only see once.
Preparing to accept payments	Currencies, payment details and payout wallets to set up before the first invoice.
An invoice in the dashboard	What an API-created invoice looks like to the person watching the dashboard.

What this version does not cover

Three things an integration may reasonably expect are missing from this version of the reference. They are listed here so you find out now rather than halfway through.

Obtaining a session JWT outside the dashboard. The sign-in flow that mints a session token is not described here, so a server-to-server integration cannot reach the JWT-only routes. Sign with an API key for everything your backend calls, and use the dashboard for the rest.
A currency reference. Requesting a withdrawal takes a currencyId, and the transaction history filters on the same field, but no endpoint documented here lists those ids. The only place one is observable today is the currency.id field on a row of the transaction history, which is no help before your first transaction. Which currencies you accept is a dashboard setting — Preparing to accept payments covers that side of it.
The webhook payload and its signature. Only the format of the webhook secret is published; the body TEDR Pay sends and the scheme for verifying it are not. Treat a callback as a hint that something changed and confirm the state with a request back to us.

Each gap is repeated as a callout on the page where it bites — the Authentication page for the JWT flow, Withdrawals for the currency ids, and Webhooks for the callback signature.