Gemini API
Gemini model access is represented by the `google-ai` provider in the integration registry. The alias map also resolves `gemini` and `google-ai-studio` to `google-ai`.
Purpose
Configure Gemini API 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.
- A Google AI API key for Gemini model access.
Setup
1
Create the credential with POST /api/integrations using provider `google-ai`, `gemini`, or `google-ai-studio`.
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 Gemini API calls.
API & contracts
| Field | Type | Description |
|---|---|---|
| google-ai | api_key | The alias map resolves `gemini` and `google-ai-studio` to `google-ai`. |
- The verifier expects an `api_key` with the `AIza` prefix.
- Project connector bindings accept the `google-ai` connector type.
- The current agentic connector registry uses a generic API-key connector for `google-ai`.
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. Gemini-specific resource fetching and provider-specific webhook handling are not implemented in the current codebase.