The four headers
Every request to the PontisGlobe API must carry these headers:| Header | Value |
|---|---|
x-api-key | Your API key from Developer Tools |
x-timestamp | Current Unix timestamp in seconds, as a string |
x-signature | HMAC-SHA256(timestamp + "." + encrypted_body, HMAC_SECRET), hex-encoded |
authorization | Bearer <JWT> — required on every endpoint except /api/v1/user/login |
The request envelope
The HTTP body is always:data field is your real payload, encrypted with AES-256-GCM using your Encryption Secret. The blob format is iv:tag:ciphertext, each component base64url-encoded:
Sign in 3 steps
Encrypt the body
AES-256-GCM with a random 12-byte IV. The key is your Encryption Secret (base64url, 32 bytes after decoding).
Sign timestamp + encrypted body
HMAC-SHA256 over the literal string
"${timestamp}.${enc}", hex-encoded.The 15-minute JWT
POST /api/v1/user/login returns:
access_token as Authorization: Bearer <token> on every endpoint that requires authentication. Tokens are bound to:
- Your consumer account (regenerating credentials invalidates active tokens immediately)
- The mode (a live JWT cannot be used in sandbox and vice versa)
401 unauthorized with code jwt_expired.
Replay protection
We reject requests wherex-timestamp drifts more than 5 minutes from server time. Keep your client’s clock in sync (NTP).
Why all of this?
| Layer | Defeats |
|---|---|
| AES-256-GCM body encryption | Passive interception (even if TLS is broken) |
| HMAC-SHA256 signature | Body tampering and request forgery |
| Timestamp in signature scope | Replay attacks |
| Short-lived JWT | Token leakage blast radius |