Providers · Beta

Keep OpenAI API spend within hard limits.

Add your OpenAI API key once. Give each app an approved model, a hard spending limit, and a fallback.

How the connection works

How OpenAI works with the gateway

01

Change the base URL, not every app

Apps call the OpenAI-compatible gateway URL with a workload key and a model alias you own. Change an eligible OpenAI model or account centrally so app teams never receive the provider key.

02

Block spend at the gateway

Set dollar budgets, request and token rates, concurrency limits, and fallback rules ahead of traffic. A provider response cannot bypass a gateway hard stop.

03

Keep prompts out of routine receipts

By default, receipts record the caller, route, model, usage, cost, policy result, and failure reason. They do not store prompts or responses. An administrator must explicitly enable transient content inspection.

Current shared controls

What every supported connection includes

Encrypted BYOK credentials that remain hidden after setup Stable model aliases and compatible route targets Organization and key budgets, rate limits, and concurrency limits Observe, Shadow, and Enforce modes with metadata-only evidence

Test the exact OpenAI model, request shape, streaming mode, and provider account as part of the production review.

Client boundary
AIGHQ_BASE_URL=https://api.aigatewayhq.com/v1
AIGHQ_API_KEY=from-your-workspace
AIGHQ_MODEL=company-approved-fast

Applications keep a stable gateway URL and model alias for OpenAI. Administrators can change eligible OpenAI accounts and models centrally.

Implemented boundary

Supported protocols

Select OpenAI and enter the API key once. The connection test checks access and does not generate tokens. Then map each app to a stable model alias.

POST /v1/responses POST /v1/chat/completions POST /v1/embeddings GET /v1/models connection test

Compatibility follows the provider's current published interface. Review the provider documentation before approving OpenAI for production.