Exchange a signed purchase intent for a token
Turn a purchase intent your wallet has signed into a token the party it names can verify for itself.
Who the token is addressed to. Omit audience and the token is addressed to you — the server fills in your own identity. Give a bare lowercase domain, such as example.com, and the token is addressed to that party; anyone may be named this way, and naming them grants them nothing on its own. Because nobody proves they control the domain they are named by, a token addressed to one carries only the identity attestations — proof of personhood, KYC status, age over 18 — and any other scope is refused. A token addressed to a domain is meant for that party’s own verification and is not accepted on Sumvin’s own endpoints.
One intent, several parties. Send the same signed intent again with a different audience and a second token is minted for that party, without asking the wallet to sign anything further. Each party’s token is separate, and all of them stop working when the intent expires or is revoked — revocation covers every token the intent has produced. One intent reaches at most ten parties; naming an eleventh is refused, and the wallet must sign a fresh intent to go further.
Addressing a new party mints a new credential rather than repeating an old one, so the checks are made again against the account as it stands now: a wallet whose verification has since lapsed cannot obtain a fresh token for a scope that requires it, and the scopes must be ones the new party is allowed to receive.
Re-sending an intent that has already been exchanged for the same audience returns the token already issued rather than minting a second.
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. In this mode the signature must be omitted, the wallet must be your primary smart wallet, and the token is always addressed to you — an audience naming anyone else is not honoured here. When false (the default), you supply the signature and choose the audience 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.
Who the minted token is addressed to. Omit it to address the token to yourself, which the server resolves to your own identity — naming your own account explicitly is refused, omit the field instead. To address a party outside Sumvin, give their bare domain in lowercase, such as example.com: no scheme, port, path or trailing dot. A token addressed to a domain may only carry the identity attestations (proof of personhood, KYC status, age over 18); any other scope is refused.
"example.com"
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