canonical: https://jentic.com/apis/enchant.com/enchant # Enchant API Jentic publishes the only available OpenAPI specification for Enchant API, keeping it validated and agent-ready. Enchant is a customer support helpdesk that organises customer conversations across email and forms into tickets, threads, and inboxes. The API exposes ticket and reply lifecycle, customer records, labels, users, inboxes, and account metadata so external tools can drive the helpdesk programmatically. Use it to embed support workflows into other systems or to automate ticket routing and replies. ## For AI agents Manage helpdesk tickets, replies, customers, labels, and inboxes in Enchant from external tools or agents. ## Scope Does not handle live chat, marketing automation, or CRM deal pipelines - use for helpdesk ticket and customer operations only. ## Capabilities - Create, list, retrieve, update, and delete support tickets in any inbox - Post replies to a ticket and read the existing reply thread - Create and update customer records and read their associated tickets - List labels for ticket tagging and routing logic - List users and inboxes to drive assignment and routing - Read account-level metadata for multi-tenant integrations ## Use cases ### External Channel to Helpdesk Bridge Convert messages from chat apps, social channels, or product feedback forms into Enchant tickets so support stays consolidated. The API exposes POST /tickets to create the ticket and POST `/tickets/{ticketId}/replies` to append agent or customer messages. Support operations teams use this to centralise their queue while keeping users in the channel they prefer. Example prompt: POST /tickets with the customer email and message body, then POST `/tickets/{ticketId}/replies` for follow-up turns from the source channel. ### Customer 360 Sync Sync customer records and ticket history into a CRM or analytics tool to give account teams a complete view of support history. The API supports listing customers, retrieving a single record with tickets, and updating contact fields, so a sync job can keep both systems aligned. Customer success and account teams use this to brief themselves before renewal calls. Example prompt: Iterate GET /customers, then GET `/customers/{customerId}/tickets` per customer to compose a support history payload for the CRM sync. ### Automated Ticket Triage Automatically tag and route incoming tickets using labels and inbox metadata so agents pick from a clean queue. The API exposes labels, inboxes, and the ticket update endpoint together. Support engineering teams use this to push triage logic out of brittle email rules and into a programmable layer. Example prompt: Call GET /labels and GET /inboxes to build the routing table, then PUT `/tickets/{ticketId}` to apply labels and reassign the ticket. ### Agent-Driven First-Response An agent watches new tickets, drafts a first response from a knowledge base, and posts the reply via Enchant when it is confident - escalating to a human otherwise. Through Jentic the agent searches by intent, loads the schemas, and executes the calls without bespoke client code. First-response time on routine tickets drops from hours to minutes. Example prompt: Search Jentic for 'reply to a support ticket', execute GET /tickets to find unanswered tickets and POST `/tickets/{ticketId}/replies` with the drafted response when the confidence threshold is met. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | `/tickets` | List tickets with filtering | | POST | `/tickets` | Create a new ticket | | PUT | `/tickets/{ticketId}` | Update a ticket | | POST | `/tickets/{ticketId}/replies` | Reply to a ticket | | GET | `/customers/{customerId}/tickets` | List tickets for a customer | | GET | `/labels` | List labels | | GET | `/inboxes` | List inboxes | ## Key resources - **Tickets** — Create, retrieve, update, delete tickets and post replies - **Customers** — Manage customer records and read their associated tickets - **Labels** — List labels available for tagging tickets - **Users** — List and retrieve helpdesk users for assignment logic - **Inboxes** — List inboxes configured on the helpdesk - **Account** — Retrieve account metadata for multi-tenant integrations ## Why Jentic - **Setup:** Wiring the Enchant API by hand means handling its bearer auth, filling in your account subdomain in the host (https://{account}.enchant.com/api/v1), and formatting ticket and customer calls yourself. Through Jentic you install once, import the Enchant API from the API Directory, store the token once, and your agent calls it. - **Permission scoping:** The Enchant API puts the ticket id in the URL path (`/tickets/{ticketId}`), so a rule can pin your agent to one ticket: it can update that ticket and post replies to it and nothing else. You choose the operations it may call, so creating new tickets is not included unless you add it. - **Credential handling:** Your Enchant token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'reply to a helpdesk ticket' or 'list a customer's tickets', and Jentic returns the matching Enchant operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Help Scout API** — Email-first helpdesk with similar ticket and customer model - **Freshdesk API** — Multi-channel helpdesk with broader feature surface - **Zendesk API** — Enterprise helpdesk with deep customisation - **Intercom API** — In-product messaging that can hand off into Enchant tickets ## FAQ ### Why is there no official OpenAPI spec for Enchant API? Enchant does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Enchant 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 Enchant API use? The API uses HTTP Bearer authentication. Send the API token in the Authorization header on every request. Through Jentic the token is held encrypted in the vault and injected at execution time, so it never enters an agent's context. ### Can I reply to a ticket programmatically with the Enchant API? Yes. POST `/tickets/{ticketId}/replies` appends a reply to the ticket thread. The reply is delivered to the customer through the same channel as the original ticket. ### How do I list a customer's tickets through Jentic? Search Jentic for 'list a customer's helpdesk tickets', load the schema for GET `/customers/{customerId}/tickets`, and execute it with the customer ID returned by GET /customers. ### What are the rate limits for the Enchant API? The OpenAPI spec does not declare quantitative rate limits; Enchant enforces limits at the account level. Treat HTTP 429 responses as authoritative and back off using the Retry-After header where present. ### Can I tag tickets with labels via the API? Yes. GET /labels lists available labels, and PUT `/tickets/{ticketId}` applies them to a ticket alongside other field updates. ### Can I limit what my agent is allowed to do with the Enchant API? Yes. Because you run Jentic One yourself, your own rules decide which Enchant operations and credentials the agent may use. Since the ticket id sits in the URL path (`/tickets/{ticketId}`), you can pin the agent to a single ticket so it can only update that ticket and post replies to it. You choose the operations it may call, so creating new tickets or reading customer records stays off unless you add them.