Adapter Spec

Influgen includes an open adapter registry for built-in and community adapters.

Registry endpoints

Current registry routes:

• GET /api/v1/adapters
• GET /api/v1/adapters/{id}/health
• POST /api/v1/admin/adapters
• DELETE /api/v1/admin/adapters/{id}

POST and DELETE are admin-only.

Registration payload

Community adapters are registered with:

• id
• name
• description
• base_url
• optional docs_url
• version
• capabilities
• optional enabled

Keep id lowercase, URL-safe, and stable over time.

Required adapter contract

Community adapters should implement the HTTP interface described by doc/ADAPTER_OPENAPI.yaml.

Minimum requirement:

• GET /health

Recommended endpoints:

• POST /generate
• POST /estimate
• POST /motion-transfer
• LoRA training or status endpoints

The adapter should return JSON compatible with core types under services/api/internal/adapter/.

Registration workflow

1. Implement the adapter service endpoints.
2. Verify GET /health returns a valid health payload.
3. Register the adapter through admin routes or UI.
4. Check GET /api/v1/adapters/{id}/health.
5. Add model registry entries that point at the adapter ID when it is ready for routing.

Health expectations

Health responses should include:

• a stable provider ID
• whether the service is healthy
• a helpful message when degraded
• a timestamp for when the check ran

If the adapter is unhealthy, set healthy=false and give operators a message that is actually actionable.

Capability naming

Capabilities should match Influgen task families such as:

• text-to-image
• text-to-video
• talking-head
• text-to-speech

Security and operations

• base_url should not contain secrets
• health endpoints should be public to the Influgen backend, not necessarily to the open internet
• registration stores registry metadata and records admin audit events

If you need organization-specific governance or approval around adapters, pair adapter registration with enterprise RBAC and audit logging.