The Playground runs real API calls from the dashboard. You pick an endpoint, fill in its parameters, press Run request, and read the actual response — no client to install and nothing to write first.
It is the fastest way to answer the question that precedes every integration: what does this endpoint actually return for my input?
The playground calls the live API with a real key. Every run costs credits at the endpoint's normal rate, and the panel tells you what a run will cost before you press the button. There is no sandbox mode.
Choosing an endpoint
The API selector at the top searches the whole catalog by name. Switching endpoints keeps you on the same page — the parameter form rebuilds from the new endpoint's schema.
The panel beside it shows the endpoint's credit cost and average latency, plus links to its full documentation and its marketplace listing. Those two numbers are worth a glance before you commit to an endpoint in a hot path.
Parameters
The form is generated from the endpoint's published schema, so it shows exactly the parameters the API accepts — with required fields marked and defaults pre-filled. There is no list to cross-reference and no way to send a parameter the endpoint does not declare.
That last point makes the playground useful as a check on your own code. An undeclared parameter sent over plain HTTP is silently dropped rather than rejected, so a typo produces a valid answer to the wrong question. If a parameter seems to have no effect in your code, run the same call here: the form will not offer a name that does not exist.
Endpoints that take a file get a drop zone instead of a text field — click or drag. Endpoints that take nothing say so, and the run button is all there is.
Choosing a key
By default the playground uses your primary key. The key selector lets you switch to any sub-key in the workspace, or paste an arbitrary key with Custom key.
Running the same call under two keys is the direct way to test a
scoping restriction: if the primary succeeds and the sub-key
returns 403, the restriction is doing its job. Guessing at whether a deny-list is configured
correctly is otherwise surprisingly hard.
Reading the response
The response panel has three tabs, and knowing which one you are on saves a certain amount of confusion:
| Tab | |
|---|---|
| Example | The endpoint's published sample. Shown before you run anything, so you can see the shape without spending a credit |
| Live | What your call actually returned. Enabled once you have run one |
| Headers | The response headers, including x-api-remaining-credits |
The panel opens on Example and switches itself to Live when a run completes. Alongside the status it shows how long the call took and how large the response was — the two numbers worth knowing before you put an endpoint in a request path.
The response can also be rendered in the other output formats, which is the
cheapest way to see what XML, YAML, CSV or Markdown will actually look like for a given endpoint
before you set an Accept header in code.
Errors render the same way — status, and the error sentence naming what to change — which means
the playground is also a good place to deliberately provoke a failure and see its exact shape
before you write the handler for it. A 400 costs nothing, so an afternoon spent breaking things
here is free.
Copy response puts the body on your clipboard, which is usually where a fixture for your tests comes from.
Ctrl/Cmd + Enter runs the request without reaching for the mouse.
Turning a run into code
Once a call works, the code panel emits the same request in:
curl · JavaScript · Node.js · Python · PHP · C# · Java · Ruby
The snippet carries the parameters you actually filled in, so it is a working call rather than a template with placeholders. Copy as cURL and Copy URL do the same for a shell or a browser.
This is the intended workflow, and it is worth using in this order:
- Get the call right in the playground, where iterating costs nothing but credits.
- Copy it in your language.
- Replace the literal key with an environment variable before it goes anywhere near a repository.
Step three is on you — the generated snippet contains the key you ran with, because the point of the snippet is that it runs.
What it does not do
The playground is a single-call tool. It does not chain calls, save requests, or keep a history — for a repeatable collection, use the Postman collection; for calling many endpoints programmatically, use an SDK or GraphQL.
It also runs from a browser session rather than from your servers, so it cannot reproduce a failure caused by your network, your proxy, or an IP allow-list that does not include the machine you are sitting at. When a call works here and fails from your code, that difference is the first place to look.
Next
All endpoints is the catalog, and each reference page documents the parameters the form here is generated from. Making requests covers what changes once you move the call out of the browser.
For the same thing on the desktop — the catalog, saved requests and a history that outlives a browser tab — see Studio.