Two endpoints with genuinely different shapes — sending uses the same Authorization: Bearer pattern as everything else, but verifying is the one endpoint in this entire API with no API-key/JWT header at all. See Magic Link for the conceptual model and the Allowed Origins setup this needs — this page is call shapes only.
POST /api/v1/magic/send
Authorization: Bearer th_test_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Content-Type: application/json
{ "email": "user@example.com" }
Real response:
{ "success": true }
Live-verified: a real email arrives, containing a real link shaped like https://<host>/api/v1/magic/verify?token=<raw-token>. (Same note as OTP: the route's own comment still claims "stdout instead of a real email" — stale, contradicted by real delivery.)
If redirectUrl isn't in your project's Allowed Origins, this returns 400 { "success": false, "error": "...", "code": "INVALID_REDIRECT_URL" } instead — see Passkey-first & smart fallback for that setup.
GET /api/v1/magic/verify?token=RAW_TOKEN
No Authorization header — the raw token in the query string is the credential. This is the literal link the user's browser follows when they click it.
Real response, captured live from an actual link click — again richer than the route's own short comment suggests:
{
"success": true,
"token": "eyJhbGciOiJIUzI1NiJ9...",
"userId": "db6a2b45-7b5e-4d2f-90e2-05e904da2637",
"user": {
"id": "db6a2b45-7b5e-4d2f-90e2-05e904da2637",
"email": "user@example.com",
"company_id": null,
"first_name": null
},
"companyId": null,
"deviceToken": "eyJhbGciOiJIUzI1NiJ9...",
"needsProfile": true,
"redirectUrl": null
}
Add &redirect_uri=https://yourapp.com/welcome (its origin must also be in Allowed Origins) and the response becomes a real 302 to ${redirect_uri}?token=<jwt> instead of JSON — for a server that wants the browser to land back on a page of its own rather than parse JSON directly.
{ "success": false, "error": "This magic link has already been used.", "code": "INVALID_TOKEN" }
401