Keys

API keys

Use a platform key to manage your account. Give your application an endpoint's dedicated key: the same key starts it, runs inference and stops it.

Use a dedicated key from your application

Dedicated key

Each optimized endpoint can have one dedicated key. Your application keeps it and uses the same key every time: Start, send requests, Stop.

  1. Get the key once Create a dedicated key from an optimized endpoint and save it in your application's secret store. It is shown once.
  2. Start GET https://www.inferoptimal.com/services/SERVICE_ID returns generation and admission.epoch. Send them to POST https://www.inferoptimal.com/services/SERVICE_ID/start with a saved idempotency_key and an expires_at within five minutes.
  3. Infer Send OpenAI-compatible requests to https://www.inferoptimal.com/services/SERVICE_ID/v1 with the same key and SERVICE_ID as the model.
  4. Stop POST https://www.inferoptimal.com/services/SERVICE_ID/stop releases the hardware. The URL and key stay the same, and requests are refused until the next Start. An idle endpoint is never stopped for you: after 30 idle minutes you get a warning email with its hourly cost and a Stop link. You can opt in to stop on idle when you create the key.

Your dedicated-key endpoints, with Start, Stop, Replace key and creating a new one, are on the Endpoints page.

A dedicated key cannot change limits, price or keys, delete the endpoint or launch anything else. Dedicated keys are for optimized endpoints; for a custom model, contact us. Request examples

Create a platform key

Management API

For your backend to quote, launch and stop endpoints. An agent connected through MCP already has this access after sign-in.

Full can start, stop and take endpoint keys. Read only can list and watch.

Platform keys

NameAccessCreatedExpiresLast used
Loading…

Keep keys on your server. A revoked key stops working within about a minute.

Use the management API

See the prompt
Use my InferOptimal account from this program.

- Read https://www.inferoptimal.com/docs/api. Use the platform key in INFEROPTIMAL_API_KEY for management; never print it or put it in source.
- Call the console API at https://www.inferoptimal.com/console/api with the header "Authorization: Bearer $INFEROPTIMAL_API_KEY". Catalog endpoints are listed at https://www.inferoptimal.com/console/optimized and my deployments at https://www.inferoptimal.com/console/endpoints.
- GET /console/api/services first, then existing deployments. Reuse a suitable dedicated-key endpoint’s stable base_url, model and saved dedicated key. A deployment with service_id belongs to that endpoint; never request a child allocation key.
- If I need a new explicit deployment, choose the model or prepared offering and POST /console/api/deployments/plan. Show the quote and limits; use my existing approval or ask for it. Then POST /console/api/deployments with the accepted plan_id and a stable idempotency_key for this job. Retry the same key if the response is lost.
- For an explicit deployment, handle readiness, POST /deployments/DEPLOYMENT_ID/connection and /deployments/DEPLOYMENT_ID/key under /console/api. Save the returned inference key in my application's secret store and use it only with the returned inference URL and model.
- Run my task; setup alone is not completion. When finished, POST /console/api/services/SERVICE_ID/stop for a dedicated-key endpoint. This drains active requests, releases the hardware and ends billing while keeping the URL and dedicated key. Before the next job, POST /console/api/services/SERVICE_ID/start with the current generation and admission epoch, a saved idempotency key and an expiry. For an explicit deployment, POST /console/api/deployments/DEPLOYMENT_ID/stop when finished. Confirm provider cleanup.
- If I want one key that starts, serves and stops an optimized endpoint, check whether dedicated keys are enabled for my account. An idle endpoint is not stopped by default; I get a warning email after 30 idle minutes, and stopping on idle is only an opt-in I set. Do not substitute a temporary deployment without explaining its lifecycle.
Explicit start and stop
  1. Quote POST /console/api/deployments/plan with your model or prepared offering and job limits. Review the returned hourly price.
  2. Create POST /console/api/deployments with plan_id and a unique idempotency_key. Reuse that key for retries of the same job.
  3. Connect Wait for inference_ready. Get /connection and /key for the deployment. The JavaScript helper handles this wait.
  4. Use and stop Send model requests to the returned URL using its inference key. Call /stop after the job; billing ends and private hardware is released.