OpenAI
The integration registry includes OpenAI. The product stores API keys, checks their format, and makes them available to generic Environment and agent connectors.
Purpose
Configure OpenAI access through the authenticated integration routes. Then use Environment monitoring, secret storage, and usage-ingestion features in the product.
Prerequisites
- A signed-in Supabase session.
- A CSRF token for POST and PATCH requests.
- An OpenAI API key.
Setup
1
Create the credential with POST /api/integrations using provider `openai` and auth_type `api_key`.
2
Use Integrations settings to attach the credential to the target Environment.
3
Send usage events through /api/v1/costs/usage-events or /api/llm/log when your backend makes OpenAI API calls.
API & contracts
| Field | Type | Description |
|---|---|---|
| openai | api_key | Provider slug accepted by the integration registry. |
- The verifier expects an `api_key` with the `sk-` prefix.
- Environment connector bindings accept the `openai` connector type.
- The current agentic connector registry uses a generic API-key connector for `openai`.
Failure modes
- POST /api/integrations returns 400 when the API key is missing or uses an invalid prefix.
- Usage ingestion returns 401 without a session and 403 for unauthorized Environment references.
- Mutation routes return 403 when the CSRF token is missing.
Partial
Credential storage, verification, connector binding, and usage ingestion are implemented. OpenAI-specific resource fetching and provider-specific webhook handling are not implemented in the current codebase.