Skip to main content
The ResQ Infrastructure API authenticates requests with a bearer JWT. You exchange a username and password for a token at POST /login, then send the token as an Authorization: Bearer <token> header on every protected request.
Operator credentials are issued out-of-band by your ResQ administrator. There is no public sign-up flow — every operator is tied to an organization and a set of mission scopes.

The flow

1

Request a token

POST /login with a JSON body like {"username": "...", "password": "..."}.
2

Read the response

On success the API returns a JWT and a Unix-second expiry timestamp.
On failure you get a 401 with an AuthError body.
3

Send the token

Attach the token to every request that targets a protected endpoint.

Token lifetime

expires_at is a Unix timestamp in seconds. Treat it as authoritative — do not parse the JWT body to derive expiry. A robust client should:
  1. Cache the token in memory only (never on disk in plaintext).
  2. Refresh proactively when fewer than 60 seconds remain.
  3. Re-authenticate from credentials on 401 Unauthorized.

Storing credentials safely

Never commit credentials to source control or pass them on the command line. Use environment variables or your platform’s secret manager.

Rotation

Rotate operator credentials at least quarterly, and immediately if a token may have been exposed. Revocation is handled server-side; clients only need to re-run the login flow.

Coordination API

The Coordination API accepts the same JWT for protected admin and mission-approval routes (for example, POST /admin/missions/approve). Public ingestion endpoints — telemetry batches, IPFS uploads — may use a separate service token issued through your administrator. Confirm the exact scheme for your deployment.

Errors you should handle

See Errors for the full envelope and status-code reference.