Playground

The console includes a runner that fires any operation against the real API, using the data of the account with an open session. It lives in the Playground tab of the API section.

The call is not made from the browser. The console sends the request to the server, which forwards it to the target operation and returns the response. The practical consequence: the API key never travels to the browser nor appears in the response, and a session left open on a shared machine does not expose it.

What can be run

The runner accepts operations of public visibility. Administration operations are out of scope, and account permissions are checked exactly as on a direct call: the runner grants no access the account lacks.

By default calls count as real in every sense: they consume quota, produce effects and appear in the account history. Running POST /v1/validate from the runner creates a validation.

Operations that carry simulation scenarios also offer a playground switch. With it on, the operation runs its real pipeline with the external step replaced by a canned answer, inside a transaction that is always rolled back: nothing is metered, no webhook is delivered, no notification is sent and no row survives. The response carries the status the real operation would have returned for the chosen scenario.

Templates

GET /v1/playground/templates returns example bodies per operation, which the runner preloads. They serve as an editable starting point, not as valid data: the sample identifiers and accounts do not correspond to real records.

Use from an integration

The runner is meant for testing from the console, not as an access layer. An integration calls the target operation directly with its own API key, as authentication describes; going through the runner adds a hop with no benefit and requires a browser session.