canonical: https://jentic.com/apis/dev.dixa.io/dixa

# Dev Dixa Dixa API

Jentic publishes the only available OpenAPI specification for Dixa API, keeping it validated and agent-ready. Dixa is a conversational customer service platform that brings email, chat, voice, and social messages into one agent workspace. The API exposes conversations, agents, end users, teams, queues, tags, custom attributes, analytics, and webhooks, so external systems can sync customer profiles, push messages into the right queue, and pull operational metrics for reporting. Used by brands like Wise, Deezer, and Too Good To Go.

## For AI agents

Manage Dixa conversations, agents, end users, queues, and analytics, plus configure webhooks and custom attributes through a comprehensive customer service API.

## Scope

Does not host live chat widgets, voice infrastructure, or knowledge base content directly - use for conversation, agent, and end-user management only.

## Capabilities

- Create and update end-user customer profiles for support routing
- Pull conversation records and route them to the right team or queue
- Manage agents - create, update, set presence, list team membership
- Configure queues, teams, tags, and custom attributes that drive routing
- Anonymise end users and conversations for GDPR compliance
- Run analytics queries to pull metrics, filters, and analytics records
- Register and manage webhooks to push events to external systems

## Use cases

### CRM-to-Helpdesk End User Sync

Customer service operations sync end-user records from a CRM into Dixa so agents see full customer context when a conversation arrives. POST `/v1/endusers` and the bulk variant create or update profiles, while PATCH lets ops keep contact details current. This avoids the agent having to ask basic identity questions during a live conversation.

Example prompt: POST `/v1/endusers/bulk` with an array of customer profiles pulled from the CRM nightly to keep Dixa end users in sync.

### Agent and Team Lifecycle Management

HR and ops teams provision Dixa agents from their identity provider, assigning them to teams as they join or move. The `/v1/agents` endpoints support create, update, and bulk operations, and `/v1/agents/{agentId}/teams` returns the agent's team memberships so tools can validate routing changes before applying them.

Example prompt: POST `/v1/agents/bulk` with the new-hire list and assign each to the right team based on role data from the HR system.

### GDPR Anonymisation Workflow

Privacy and legal teams handle GDPR right-to-erasure requests through PATCH `/v1/endusers/{userId}/anonymize.` This scrubs personally identifying information from the end user record while preserving the conversation history needed for audit. Most teams pair this with a ticketing flow to track each request through to anonymisation.

Example prompt: PATCH `/v1/endusers/{userId}/anonymize` for each verified GDPR erasure request and log the request ID against the audit trail.

### Operational Analytics Pipeline

Support ops teams pull conversation metrics and filter dimensions through the `/v1/analytics/metrics`, `/v1/analytics/records`, and `/v1/analytics/filter` endpoints to drive their own dashboards in BI tools. POSTing to `/v1/analytics/metrics` or `/v1/analytics/records` lets teams define the slice they need rather than working off canned reports.

Example prompt: POST `/v1/analytics/records` with a filter for the past 7 days, then load the returned records into the BI warehouse for a weekly support performance dashboard.

### Agent-Driven Customer Service Automation

AI agents help Dixa supervisors triage queues, anonymise users, and pull analytics through Jentic. The Dixa API key sits in your Jentic One instance, so the agent can resolve intents like 'list all open conversations for the billing team' without holding credentials.

Example prompt: Search Jentic for 'list Dixa agents on a team', load the GET `/v1/agents/{agentId}/teams` operation, and execute it for the requested agent ID.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/v1/endusers` | Create an end-user record |
| POST | `/v1/endusers/bulk` | Bulk-create end-user records |
| PATCH | `/v1/endusers/{userId}/anonymize` | Anonymise an end user for GDPR |
| POST | `/v1/agents` | Create an agent |
| POST | `/v1/agents/bulk` | Bulk-create agents |
| GET | `/v1/agents/{agentId}/teams` | List teams an agent belongs to |
| POST | `/v1/analytics/records` | Query analytics records |
| GET | `/v1/agents/presence` | List agent presence states |

## Key resources

- **Conversations** — Customer conversation records across channels
- **Agents** — Manage agent profiles, presence, and team membership
- **End Users** — Customer profile records for support routing
- **Teams** — Team configuration that drives routing
- **Tags** — Conversation tags for categorisation
- **Analytics** — Metrics, filters, and records for reporting
- **Webhooks** — Outbound event subscriptions
- **Queues** — Routing queues for incoming conversations

## Why Jentic

- **Setup:** Wiring the Dixa API by hand means learning its API key header and building the end-user, agent, team, and analytics calls across its large surface, including the bulk and anonymize variants, yourself. Through Jentic you install once, import the Dixa API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** Dixa identifies end users and agents by id, so you limit the agent to the operations it needs, such as creating end users or reading agent presence, and the destructive end-user anonymization at `/endusers/{userId}/anonymize` is included only if you add that operation.
- **Credential handling:** Your Dixa API key is stored once, encrypted, by your own Jentic One instance and injected into the request header at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a Dixa end user' or 'read agent presence', and Jentic returns the matching Dixa operation with its input schema so the agent calls the right endpoint without browsing Dixa's large surface.

## Related APIs

- **Zendesk API** — Zendesk is a broader competing helpdesk with a larger ecosystem of apps and integrations.
- **Freshdesk API** — Freshdesk is a competing helpdesk strong on ticketing workflows.
- **Intercom API** — Use Intercom for in-product messaging alongside Dixa for cross-channel support.

## FAQ

### Why is there no official OpenAPI spec for Dixa API?

Dixa does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Dixa API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Dixa API use?

Dixa uses an API key passed in a request header (ApiKeyAuth scheme). Through Jentic the key is stored encrypted in the vault and injected at execution so the raw value never enters agent context.

### Can I bulk-create end users with the Dixa API?

Yes - POST `/v1/endusers/bulk` accepts an array of end-user objects, which is the recommended approach for nightly CRM-to-Dixa syncs over more than a handful of records.

### How do I anonymise an end user for GDPR with the Dixa API?

Call PATCH `/v1/endusers/{userId}/anonymize.` Personally identifying information on the end user record is scrubbed while conversation history is preserved for audit.

### What are the rate limits for the Dixa API?

The OpenAPI spec does not declare specific rate limits. For high-volume workloads, prefer bulk endpoints (`/v1/endusers/bulk`, `/v1/agents/bulk`) and implement exponential backoff on 429 responses.

### How do I pull conversation analytics through Jentic?

Search Jentic for 'query Dixa analytics records', load the POST `/v1/analytics/records` operation, and execute it with the filter payload. Jentic injects the API key at execution and returns the query results.

### Can I limit what my agent is allowed to do with the Dixa API?

Yes. Because you run Jentic One yourself, your own rules decide which Dixa operations and credentials the agent can use, so you can grant only what a given task needs, such as creating end users or reading agent presence, and withhold everything else. Since Dixa identifies end users and agents by id, you scope the agent to those specific operations rather than its full surface. The destructive anonymization at PATCH `/endusers/{userId}/anonymize` is available to the agent only if you deliberately add that operation.