Authentication — Authenticate TSN service calls - TSN

TSN separates public signed application requests from privileged worker and Cranker operations.

Public application calls

POST /intents, GET /settlement-networks, GET /network/overview, GET /epoch/status, and GET /metrics do not declare require_worker_api_key in the Node source. Payment intents still require the signed authorization fields validated by _verify_payment_authorization_from_signed_message.

Worker authentication

Privileged Node endpoints use Depends(require_worker_api_key) and expect the configured worker key in the x-api-key header. The SDK’s TsnHttpClient adds this header when apiKey is supplied.

import { TsnHttpClient } from "@trustlink/tsn-sdk";

const worker = new TsnHttpClient({
  baseUrl: process.env.TSN_NODE_URL!,
  apiKey: process.env.TSN_NODE_API_KEY,
});

const work = await worker.get("/intent-work?limit=50");

Receiver and Cranker admission

The Receiver and Cranker admission boundary is separate from the public Node API. The Cranker SDK obtains its operator keypair from KEYPAIR_PATH; the source does not document a public API-key substitute for on-chain Mother-DNA admission.

Parameters and responses

Credential	Required	Sent as	Failure observed in source
Worker API key	For worker-protected routes	`x-api-key`	HTTP 401/403 according to `require_worker_api_key`; exact deployment configuration is environment-controlled.
Payment authorization signature	For `/intents`	JSON request fields	HTTP 4xx when the signed message, expiry, route commitment, or signature is invalid.
Cranker keypair	For Cranker SDK commands	Local signer	CLI throws when `KEYPAIR_PATH` is missing or the keypair file cannot be loaded.

TODO: confirm the exact deployed Receiver header names and status body from the Receiver repository’s production route configuration before publishing a Receiver-specific authentication page. Source: server.py:374-383, client.ts:1-67, cli.ts:20-48