The Zest Partner API uses the OAuth 2.0 JWT-Bearer assertion grant (RFC 7523). Each call presents a short-lived bearer token; partners exchange a self-signed JWT to mint that token.Documentation Index
Fetch the complete documentation index at: https://docs.zestequity.com/llms.txt
Use this file to discover all available pages before exploring further.
Flow
Build a JWT assertion
Sign a JWT with the EdDSA private key registered with Zest. Claims are listed below.
POST to /v1/oauth2/tokens
Body:
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=<JWT>. Response: { accessToken, tokenType, expiresIn }.Required JWT claims
| Claim | Description |
|---|---|
iss | Your API base URL (acts as your issuer identifier). |
sub | Your client_id. |
aud | Zest API base URL of the environment you’re calling — exactly https://api.zestequity.com or https://sandbox.api.zestequity.com. |
client_id | Your client_id (must match sub). |
iat | Issued-at, unix seconds. |
exp | Expiry, unix seconds. Keep short — 60 seconds is recommended. |
Token exchange request
Code samples
Python
Node.js
Common pitfalls
invalid_token / 401 — clock skew
invalid_token / 401 — clock skew
Zest tolerates only a few seconds of skew between your clock and ours. If your server clock drifts (common on bare-metal lab machines or some Docker hosts), JWT
iat / exp checks fail. Fix by enabling NTP / chrony.invalid_token / 401 — audience mismatch
invalid_token / 401 — audience mismatch
The
aud claim MUST exactly equal the base URL of the environment you’re calling. Sandbox tokens used against production (or vice versa) are rejected.invalid_token / 401 — algorithm mismatch
invalid_token / 401 — algorithm mismatch
JWT MUST be signed with EdDSA. RSA / HMAC assertions are rejected as a defence-in-depth measure.
invalid_token / 401 — sub != client_id
invalid_token / 401 — sub != client_id
Both claims are required and must match each other. They identify the partner application.