Modal
Modal is now a first-class provider slug in the integration registry. The current implementation stores Modal credentials, validates token fields, and exposes them to generic project and agent connectors.
Purpose
Configure Modal 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 Modal token_id and token_secret pair.
Setup
1
Create the credential with POST /api/integrations using provider `modal` and auth_type `api_key`.
2
Supply `token_id` and `token_secret` in the credentials payload or through the integrations settings UI fields.
3
Attach the credential to a project or environment after verification succeeds.
API & contracts
| Field | Type | Description |
|---|---|---|
| modal | api_key | Provider slug accepted by the integration registry. |
- The verifier requires both `token_id` and `token_secret`.
- Project connector bindings accept the `modal` connector type.
- The current agentic connector registry exposes Modal through a generic API-key connector.
Failure modes
- POST /api/integrations returns 400 when Modal credential fields are missing.
- Mutation routes return 401 without a session and 403 when the CSRF token is missing.
- Project binding fails when the selected credential is not in `connected` status.
Partial
Credential storage, verification, and connector binding are implemented. Modal-specific resource fetching, deployment sync, and webhook handling are not implemented in the current codebase.