Exchange Pint
Authorizations
JWT issued by Dynamic Labs or Privy. Sent in the x-juno-jwt header on every authenticated request.
Headers
Tenant org ID for multi-tenant auth
Controls how timestamp fields are serialized in JSON response bodies.
Default (header omitted or any other value): epoch milliseconds as integers.
iso8601: UTC ISO 8601 strings of the form YYYY-MM-DDTHH:MM:SSZ.
Example: with X-Timestamp-Format: iso8601, the field value 1704067200000 becomes "2024-01-01T00:00:00Z".
Affected fields (recursively, in dicts and arrays): any field whose name ends in _at, plus the literal field names timestamp, period_start, and period_end. All other fields are passed through unchanged.
Only iso8601 is recognized. Any other value (or omitting the header) yields the default epoch-ms representation; the server does not reject unknown values, so this is documented as an example rather than an enum to keep generated clients permissive.
"iso8601"
Query Parameters
Set to true to have the server sign the purchase intent with your own agent signer and address the token to you. In this mode the signature must be omitted and the wallet must be your primary smart wallet. When false (the default), you supply the signature; name a third party in audience, or omit it to address the token to yourself.
Body
The wallet's EIP-712 signature over the purchase intent, 65 bytes hex with a 0x prefix. Required for direct minting. Omit it when minting with agent=true, where the server signs on the caller's behalf.
The identifier of the third party the minted token is addressed to. Omit it to address the token to yourself, which the server resolves to your own identity. It must not name your own account — omit it instead.
Optional chat message ID correlating this PINT back to the conversation that generated it. When provided, the message must belong to a chat session owned by the authenticated user.
12345
Optional URI of an existing PINT this one is allocated against, recording the lineage between them. The parent must belong to the same wallet as this PINT and must itself authorise a purchase that is still open to further spending — an allocation against a purchase that has finished, expired or been cancelled is refused. A PINT allocated against a parent must stay within what the parent authorises: its scopes must be exactly those the parent permits for the requested amount — the same currency and card, with the amount within the parent's limit — its top-level max_amount and max_amount_token must be zero (the spending ceiling is carried by its checkout scope), and it may not expire after the parent. A request that does not match is refused.
512"sr:us:pint:9f2c1e7a4b8d"
Response
Successful Response