How Do You Build a Custom Zendesk Integration When There's No Native App? (2026)

To connect Zendesk to a tool that has no Marketplace app, define the action you need (look up an order, create a Jira issue, check a subscription) as a Custom Tool pointed at that tool's API, and let an AI agent call it while it works the ticket. You set the endpoint, method, authentication and parameters once, mark the tool Read or Write, and there's no app to ship, no marketplace review and no integration code. Zendesk's own route for its native AI agents is custom actions, which replaced the integration builder for new integrations.

First, the framing. Macha isn't a Zendesk replacement. It runs on top of the Zendesk you already use. Your agents keep working in the Zendesk Agent Workspace; Macha adds an AI layer that can read tickets, reason, and, through Custom Tools, reach into any other system to answer or act.

What does "custom integration" mean now?

For years, "integrating X with Zendesk" meant one of two things: find a pre-built Marketplace app, or pay a developer to build one against the Zendesk Apps framework and the target tool's API. Both are heavy. A Marketplace app is someone else's idea of the integration; a bespoke one is a project with a maintenance tail.

A Custom Tool is a third path. Instead of building an app, you define an action ("look up an order," "create a Jira issue," "check a subscription in our billing system") and point it at the relevant API endpoint. Your Macha AI agent then calls that action while it works a ticket, passes the right parameters, and reasons over what comes back. No marketplace listing, no app review, no glue code.

The difference in practice is control. A native app does what its author decided it should do. A Custom Tool does exactly what you describe, scoped to the one job you need, in the language your team uses.

How do you build a Custom Tool for Zendesk?

Every Custom Tool follows the same shape, whether it wraps Salesforce, a Postgres-backed internal API, or a microservice.

1. Point it at the API. You give Macha the endpoint, method, and credentials. If you'd rather not fill in a form, Sidekick, Macha's in-dashboard builder, will scaffold the tool from a plain-English description: "connect Stripe to look up payments," "hook up our internal orders API."

2. Define the action. Give the tool a label and a description the AI uses to decide when to call it, set the method (GET, POST, PUT, PATCH or DELETE) and URL, with placeholders like {{order_id}} for the parameters the agent will fill, and choose whether it's a Read or a Write. Reads fetch data; Writes create, update or delete it. Authentication, static headers, and response mapping (a dot-path such as data.results so the agent only sees the part of the response it needs) are all here too, so a real production endpoint drops straight in.

3. The agent uses it live. Once the tool exists and is assigned to an agent, the agent calls it mid-ticket. A customer asks "where's my order?" in a Zendesk ticket; the agent recognizes the intent, calls Get Order Status with the order ID it pulled from the conversation, and answers with the real status and tracking from your system of record.

That's the loop: define once, and the agent decides when to use it on every relevant ticket after that.

What does a library of Custom Tools look like?

Custom Tools aren't a one-off escape hatch. Teams build a small library of them, grouped by the service they wrap. Here's a Macha workspace with tools for Postmark (list templates, send email) and a store's order-lookup endpoint, each tagged Read or Write with its API URL.

Notice the mix of GET/Read and POST/Write. An agent can be allowed to look up anything but only act (send, refund, update) through the specific Write tools you assign it.

How do Read vs Write, auth and permissions keep it safe?

Because a Custom Tool can reach into real systems, the guardrails matter as much as the capability:

• Read vs Write. Read tools only fetch data. Write tools ask the user for confirmation before they run in chat. Once an agent runs autonomously on a trigger, there's no confirmation step, so a Write tool executes immediately; test the agent before you switch the trigger on.
• Scoped by design. A tool exposes one action against one endpoint. It does the job you defined and nothing else.
• Assigned per agent. An agent can only use tools explicitly assigned to it. Your triage agent might only read; a senior-support agent might be allowed to write.
• Reviewable. Autonomous runs show up in the agent's history, and Agent Evaluation grades completed conversations against the agent's instructions, so you can check what ran and why.

For authentication, the builder supports API keys in a custom header, bearer tokens and HTTP Basic auth. Credentials are encrypted at rest and never exposed to the AI model, so tools that need them (most of them) work without secrets appearing in the conversation.

When should you use a native app instead of a Custom Tool?

Custom Tools don't make the Marketplace obsolete; they cover what it can't.

• Reach for a native app when a well-maintained one already exists for a mainstream tool and does what you need out of the box: Slack notifications, a Jira sidebar, a Shopify order card. If Macha has a native connector for it, use that (it's deeper and needs no setup).
• Reach for a Custom Tool when there's no app, the app is limited or read-only, the tool is internal or industry-specific, or you need a specific action the app doesn't expose.

Zendesk has its own no-code option for its AI agents. The integration builder connected Zendesk AI agents to APIs across messaging, email and voice, on every Suite plan and on Support Team, Professional and Enterprise. Zendesk now says new API integrations should be built as custom actions instead, with the old menu kept for maintaining existing ones. Either way, the result only works inside Zendesk's agent framework. A Macha Custom Tool is portable: the same action works on Zendesk, Freshdesk, Gorgias, Front, HubSpot or Intercom, and you can describe it in plain English instead of living inside one vendor's builder. That's the incentive difference too: Zendesk's builder exists to make its per-resolution AI agents more useful, so it stays inside Zendesk.

The rule of thumb: if you've ever said "I wish Zendesk could just check X for me," and X has an API, that's a Custom Tool.

Which Custom Tools are worth building first?

The pattern generalizes across every category of tool a support team touches:

• CRM: pull a customer's account, plan, and owner from Salesforce or HubSpot into the ticket.
• Databases & warehouses: query orders, subscriptions, or usage through an API over Postgres, Snowflake, or BigQuery to answer from the source of truth.
• Billing & payments: check a subscription or issue a refund in Chargebee, Recurly, or Stripe.
• Engineering: open a Jira, Linear, or GitHub issue from a bug report and read its status back.
• Internal systems: hit your own admin API to look up an account, reset a flag, or trigger a job.

For a browsable list of tools you can connect this way, 200+ across CRM, databases, e-commerce, ITSM, and more, see the Custom Tools integration directory. If it has an API, it belongs on that list.

Running more than one help desk? The same approach works on Freshdesk, Front, Intercom, Gorgias and HubSpot, because a Custom Tool doesn't depend on the help desk it's called from.

How long does it take to go from missing app to working integration?

Usually one sitting. You describe the action, point it at the API, assign it to an agent, and test it before the agent runs on live tickets. You don't have to do that part yourself: anything with an API can become a Custom Tool that the Macha team builds and tests for you as part of setup, on the trial and every plan. Macha costs about $0.40 a ticket, from $299 a month for 750 tickets, and that includes setup and a dedicated success manager who handles your changes, such as a new tool or an instruction update. See how Custom Tools work, browse the integration directory, or start a free trial ($50 of usage, no credit card) and wire up your first tool.

Frequently asked questions

Do I need an engineer to build a Custom Tool for Zendesk? No. You can describe the integration in plain English and Sidekick scaffolds the request, authentication, and parameters. Technical teams can go deeper with full control over methods, headers, bodies, and response mapping.

Is this a Zendesk Marketplace app? No. A Custom Tool doesn't need a Marketplace listing or app review. It's an action your AI agent calls against any API, so you can connect tools that will never have a native app, including internal and industry-specific systems.

Which help desks does this work with? Macha runs on Zendesk, Freshdesk, Gorgias, Front, HubSpot or Intercom. It sits on top of the help desk you already use, and Custom Tools work the same way across all of them.

Can it change data, or only read it? Both. Read tools fetch data; Write tools (refunds, updates, status changes) ask for confirmation in chat. In autonomous runs they execute without a confirmation step, so you control risk by choosing which agents get Write tools and testing before going live.

Is it secure? Custom Tools are scoped to a single action and only usable by agents they're assigned to. Credentials are encrypted at rest and never exposed to the AI model, and autonomous runs are recorded in the agent's history.

How is this different from Zendesk custom actions? Zendesk custom actions, the successor to its integration builder, connect Zendesk's own AI agents to APIs and only work inside Zendesk. A Macha Custom Tool works on every help desk Macha connects to and is billed per ticket, not per automated resolution. The Macha team builds and tests your first Custom Tools for you as part of setup, included at about $0.40 a ticket.