Skip to main content

​
1. Create a key and find a model

Sign in to the console and check your account status. An active account can create an API key. Copy the key when it is shown and keep it on your server.
The response is a data list. Choose an available base model; catalogue entries can also be unavailable or require early access. A waitlisted account can view the catalogue and its own account, but cannot run authenticated decisions yet.

​
2. Send a decision

This request routes a message and defers uncertain cases. The 0.8 threshold is an example policy to evaluate on your own messages.
The timeout above is your client’s waiting budget. A timeout does not prove that the server stopped or that no charge occurred.

​
3. Use the action

Given the parsed response as result:
top is the most probable raw outcome. action also accounts for any weights, costs and abstention policy. When you declare a policy, use its action and handle abstained explicitly. Inspect usage.input_tokens and usage.decisions for the request’s usage. Use the account usage endpoints for costs. Record X-Request-ID when diagnosing an error; the decision id identifies the returned decision and can be used for feedback if you requested storage.
Persist an Idempotency-Key with the request and reuse both after a timeout. Successful inference responses can be replayed for 24 hours without another charge. Once the response expires, that key returns an explicit error and never runs another inference. store: true independently enables feedback. See reliable retries.

​
Next steps

Try support routing to combine all three kinds, or write clearer decisions. The API behavior guide covers errors, limits and pagination. The API reference’s interactive playground sends requests through Mintlify’s proxy to the live console API. The supplied key and request pass through that proxy; successful calls can consume credit or create resources. Use sample data and a key you can revoke.