Authentication

All Tenzro Platform API requests require authentication using API keys. This guide covers how to obtain, configure, and secure your API credentials.

API Keys

API keys are created in the Tenzro Platform dashboard. Each key is scoped to a specific tenant and can have granular permissions.

Key Format

Tenzro Platform API keys use the tenant-prefixed format:

# Format: tnz_<tenant_prefix>_<base64url_secret>

Examples:
  tnz_53ee34cc_YqKz10cxaA-xncxDbPnnmmXC7MktUKzNAGPJSidRh4Q
  tnz_mycompany_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The tenant ID is embedded in the key and can be automatically extracted by the SDK, so TENZRO_TENANT_ID is optional when usingtnz_ prefixed keys.

Centralized API Key Validation

All Tenzro Platform services use centralized API key validation through the API Keys service. This ensures consistent authentication across all services including Token, Ledger, Bridge, Anchor, AI, Wallet, and Custody.

  • API keys are validated in real-time against the centralized API Keys service
  • Rate limiting and usage tracking are enforced centrally
  • Health endpoints (/health) are public and do not require authentication
  • All other API endpoints require valid API key and tenant ID headers

Request Headers

Include these headers with every API request:

HeaderDescriptionRequired
X-API-KeyYour API key (tnz_*)Yes
X-Tenant-IdYour tenant identifier (UUID format)Yes
Content-Typeapplication/json for POST/PUT/PATCHFor body requests
X-Idempotency-KeyUnique key for idempotent requestsRecommended
X-Request-IdUnique request ID for tracing (auto-generated if not provided)Optional
X-NetworkTarget network: devnet, testnet, or mainnetOptional (defaults to devnet)
X-API-VersionAPI version number (defaults to 1)Optional

Response Headers

All responses include these headers for tracing and versioning:

  • X-Request-Id - Unique request identifier for log correlation
  • X-API-Version - API version used for the request
  • X-API-Version-Deprecated - Present if using a deprecated API version

Example Request

curl -X POST "https://api.platform.tenzro.com/api/wallet/create" \
  -H "X-API-Key: tnz_53ee34cc_YqKz10cxaA-xncxDbPnnmmXC7MktUKzNAGPJSidRh4Q" \
  -H "X-Tenant-Id: 550e8400-e29b-41d4-a716-446655440000" \
  -H "Content-Type: application/json" \
  -H "X-Idempotency-Key: unique-request-id" \
  -H "X-Request-Id: req_abc123" \
  -d '{"name": "Treasury", "type": "custody"}'

Public Endpoints (No Auth Required)

The following endpoints do not require authentication:

  • GET /health - Service health check
  • GET /ready - Service readiness check
  • GET /metrics - Prometheus metrics (internal)

API Key Scopes

API keys can be restricted to specific services and operations:

ScopeDescription
wallet:readRead wallet information
wallet:writeCreate and modify wallets
token:transferExecute token transfers
bridge:executeExecute cross-chain transfers
custody:signSign transactions
ledger:readRead ledger entries
ledger:writeCreate ledger entries
ai:inferenceRun AI inference
anchor:writeAnchor data to blockchain
admin:*Full administrative access

Key Rotation

API keys should be rotated regularly. The platform supports zero-downtime rotation:

// Create a new key before revoking the old one
const newKey = await platform.apiKeys.create({
  name: 'Production Key v2',
  scopes: ['wallet:*', 'token:*', 'bridge:*'],
  expiresAt: '2027-12-31T23:59:59Z',
});

// Update your application to use the new key
// Then revoke the old key
await platform.apiKeys.revoke('old-key-id');

Security Best Practices

  • Never expose keys in client-side code - API keys should only be used in server-side applications
  • Use environment variables - Store keys in environment variables, never in source code
  • Restrict scopes - Only grant the minimum permissions needed
  • Set expiration dates - Use short-lived keys when possible
  • Monitor usage - Review API key usage in the dashboard regularly
  • Use IP allowlists - Restrict API key usage to specific IP addresses

Rate Limiting

API requests are rate limited per API key. Current limits are returned in response headers:

HeaderDescription
X-RateLimit-LimitMaximum requests per window
X-RateLimit-RemainingRequests remaining in window
X-RateLimit-ResetUnix timestamp when limit resets

When rate limited, requests return 429 Too Many Requests with aRetry-After header.

Error Responses

Authentication errors return appropriate HTTP status codes:

StatusErrorDescription
401UnauthorizedMissing or invalid API key
403ForbiddenKey lacks required scope
429Too Many RequestsRate limit exceeded