OpenAI
OpenAI is a first-class provider slug in the integration registry. The current implementation stores API keys, validates the key format, and exposes the credential to generic project and agent connectors.
Purpose
Configure OpenAI access in ActsAsGeek through the authenticated integration routes, then use the project monitoring, secret storage, and usage-ingestion surfaces that already exist 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
Attach the credential to the target project or environment in the integrations settings surface.
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.
- Project 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 project 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.