Twenty Crm

Twenty's primary API is GraphQL with a well-documented schema introspectable at /metadata. REST API is available for some endpoints. GraphQL mutations cover create, update, delete, and batch operations on CRM objects. Custom objects are first-class in the API. Filtering, pagination (cursor-based), and sorting are supported. API versioning uses major version prefixes. SDK support is limited; direct GraphQL calls are the standard pattern. The API is clean but requires familiarity with GraphQL conventions.

Twenty is an open-source CRM designed as a modern HubSpot alternative, with a GraphQL API as its primary data interface. Agents can programmatically manage contacts, companies, deals, tasks, and custom objects via the API. The data model is workspace-based with custom field support. Twenty Cloud is a managed offering; self-hosting is supported via Docker. Webhooks are available for CRM events. API key auth is supported. Agent relevance is solid for B2B workflow agents: contact enrichment, deal stage management, and task creation are all API-accessible. Confidence is docs-derived; the product is actively developed and API surface is stabilizing.

Authentication uses API tokens generated in the Twenty workspace settings. Bearer token auth on all API requests. No OAuth flow for machine-to-machine — API key is the agent auth pattern. Workspace-scoped tokens; no per-resource scoping documented. Token rotation is manual via the dashboard. Straightforward API key model for agent use.

Documentation at docs.twenty.com covers setup, data model, API reference, and webhooks. GraphQL schema is introspectable. Self-hosting guide is detailed. Community Discord is active. REST API docs are less complete than GraphQL docs. The project is pre-1.0 (as of early 2026); some docs may lag behind the codebase. GitHub is the authoritative source for edge cases.

GraphQL errors return in the standard errors array with message and extensions fields. HTTP 400 for malformed queries, 401 for invalid tokens, 200 with errors array for application-level errors (standard GraphQL pattern). Validation errors include field-level details. No retry-after headers documented. The service is actively developed — breaking changes are possible between minor versions during the pre-1.0 phase.