Exchange a ticket | INFONITE

Turn the ticket an execution issued into a reusable token.

Why this exists. Running an engine every month should not mean keeping somebody’s bank password in your database. Tokenization moves that problem: you run the credentials once, we keep them encrypted, and you keep a token that only works for that engine, that customer and that set of features — through your application and no other.

Neither half opens the credentials alone. The key you receive here is not the encryption key: it is one input to a derivation that also needs a secret living only in our runtime, and the result — an AES-256-GCM key — exists only for the moment it is used. We store the ciphertext and a non-reversible verifier of your key, never the key itself. The full design is in the Credential Tokenization guide.

How you get here. Start an execution with base_configurations.tokenized_access: true. If your application is allowed to tokenize, the 202 carries a ticket. That ticket is single-use and short-lived: it exists to be exchanged, here, for the real token.

What you get back. A token_id and a token_key, plus the context the token is locked to: engine, customer, the locking_hash of the credentials, and the features it may request. Store both halves and treat the key like a password — it is the only copy, nothing on our side holds it, and it is never shown again. Lose it and the stored credentials can no longer be opened by anyone: revoke the token and mint a new one from a fresh run with the real credentials.

The token expires 90 days after this exchange, and using it does not extend that. The expiry is fixed when the token is minted; when it passes, the stored credentials are deleted. Track date_expiration and mint a fresh token — from a new parametrized execution — before it lapses. Send it to Start a Tokenized Execution.

A 403 covers every way this can fail — no such ticket, wrong ticket, already exchanged, tokenization not enabled. That is deliberate: an attacker guessing tickets learns nothing from the answer.

This endpoint needs to be executed with an app secret, so should always be used in server side without exposing the secret to customers.

Turn the ticket an execution issued into a reusable token. **Why this exists.** Running an engine every month should not mean keeping somebody's bank password in your database. Tokenization moves that problem: you run the credentials once, we keep them encrypted, and you keep a token that only works for that engine, that customer and that set of features — through your application and no other. **Neither half opens the credentials alone.** The key you receive here is not the encryption key: it is one input to a derivation that also needs a secret living only in our runtime, and the result — an AES-256-GCM key — exists only for the moment it is used. We store the ciphertext and a non-reversible verifier of your key, never the key itself. The full design is in the [Credential Tokenization guide](/guides/credential-tokenization). **How you get here.** Start an execution with `base_configurations.tokenized_access: true`. If your application is allowed to tokenize, the `202` carries a `ticket`. That ticket is single-use and short-lived: it exists to be exchanged, here, for the real token. **What you get back.** A `token_id` and a `token_key`, plus the context the token is locked to: engine, customer, the `locking_hash` of the credentials, and the features it may request. **Store both halves and treat the key like a password** — it is the only copy, nothing on our side holds it, and it is never shown again. Lose it and the stored credentials can no longer be opened by anyone: revoke the token and mint a new one from a fresh run with the real credentials. **The token expires 90 days after this exchange, and using it does not extend that.** The expiry is fixed when the token is minted; when it passes, the stored credentials are deleted. Track `date_expiration` and mint a fresh token — from a new parametrized execution — before it lapses. Send it to [Start a Tokenized Execution](api:POST/executions/init/v1/tokenized). A `403` covers every way this can fail — no such ticket, wrong ticket, already exchanged, tokenization not enabled. That is deliberate: an attacker guessing tickets learns nothing from the answer. > This endpoint needs to be executed with an app secret, so should always be used in server side without exposing the secret to customers.

Authentication

X-APP-SECRETstring

Application Secret

Request

This endpoint expects an object.

execution_idstringRequiredformat: "object-id"

The execution whose ticket you are exchanging — the one you asked tokenized access for.

ticketstringRequired=64 characters

The ticket that execution returned. Single-use: this call spends it.

Response

200 OK
The token, and the only copy of your half of the key. Store both: the key is not recoverable and we do not keep it — without it the credentials cannot be opened, by us or by anyone.

The ticket is spent by this call. Asking again with the same one answers 403.

**200 OK**<br>The token, and the **only copy of your half of the key**. Store both: the key is not recoverable and we do not keep it — without it the credentials cannot be opened, by us or by anyone. The ticket is spent by this call. Asking again with the same one answers `403`.

tokenobject

Credentials token containing the token ID and key.

contextobject

Credentials context.

Errors

403

Forbidden Error

422

Unprocessable Entity Error

Turn the ticket an execution issued into a reusable token.

A 403 covers every way this can fail — no such ticket, wrong ticket, already exchanged, tokenization not enabled. That is deliberate: an attacker guessing tickets learns nothing from the answer.

This endpoint needs to be executed with an app secret, so should always be used in server side without exposing the secret to customers.