Sending an inference request

Send a purchased request

Open Send an inference request from API access. The screen sends one real text chat request through a purchased agreement. It reserves allowance before dispatch and settles against validated supplier usage. It is not a free trial.

Only buyer accounts with access to the agreement and an authorized API key can use this screen. Approved providers manage supply rather than buyer API keys.

Choose the capacity

In Choose purchased capacity, select a Purchased agreement, then an API key authorized for it. The agreement list includes your organization's purchased routes that currently admit this text-chat test, including its 128-token output limit. An embedding-only route does not appear as a chat choice. Selecting an agreement also fixes the exact purchased model; there is no separate model entry or automatic substitution. Keys restricted to a different agreement are not offered. If no compatible key or eligible agreement appears, use the link on the screen to create a key or review your agreements.

Enter a short Prompt, then select Send inference request. The button shows that the request is pending until the server responds. Avoid sensitive content in a test prompt. The gateway checks key scope, the model, delivery window, allowance, capacity, and supplier route before dispatch. A listed agreement can still fail if an operational condition changes between loading the page and sending the request.

Read the actual response

Actual response renders the returned text and shows the request ID and metered input, output, and total tokens when supplied. Complete metered usage shows the full returned usage object. If usage is unavailable, review the durable record in Usage and allowances; do not treat a missing count as free work.

An error displays the server's message. A failed or interrupted browser request can have an uncertain supplier outcome. Check Usage & reconciliation before trying a new request. Creating another key will not repair an unavailable supplier route or exhausted allowance.

The screen retains the same idempotency key for an unchanged key, agreement, model, and prompt after a failed attempt, so the gateway can recognize a retry. Changing any of those inputs or receiving a confirmed success starts a new key. A second send after success is a new request that may consume allowance again.

Use the purchased agreement from your application

The screen displays a curl example with your selected model and agreement ID. Replace the example API key and unique request ID. The application must send its raw buyer key in Authorization, its purchased agreement ID in X-Agreement-Id, and the exact purchased model in the request body. Keep raw keys in your application's secret store; do not paste them into RFQs or support requests. See API access for key creation and Troubleshooting for recurring failures.