How Do You Connect a Tool to Intercom With No App Store App? (2026)

If the tool you need isn't in the Intercom App Store but has an API, you can connect it two ways: Intercom's own Data connectors (the feature earlier guides call Custom Actions), which a teammate configures in four phases, or a Macha Custom Tool, where you describe one action, point it at the endpoint and mark it Read or Write. Both let an AI agent pull the real order or subscription mid-conversation. The difference is how much configuration you own and whether the same action works on your other help desks.

Intercom's Data connectors documentation lays out the native setup: configure the HTTPS endpoint, method, headers and authentication; shape the response by restricting fields or transforming it with Python code blocks; choose automatic triggering for read-only queries or manual triggering for sensitive operations; then run the security step. Intercom notes that user authentication must be configured before a data connector can go live for users. That's the right tool for some teams. For everyone else, there's a lighter path.

First, the framing. Macha isn't an Intercom replacement. It runs on top of the Intercom you already use through a native Intercom connector that reads conversations, replies, adds internal notes, assigns, tags and closes. Fin and your Inbox keep working as they do; Macha adds an AI layer that can reason over a conversation and, through Custom Tools, reach into any other system to answer or act.

What does "custom integration" mean for Intercom now?

Historically, "integrating X with Intercom" meant one of three things: find an App Store integration, configure an API action inside Intercom, or pay a developer for a bespoke build. All three are real, and all three carry weight. An App Store app is someone else's idea of the integration; a native API action or bespoke build is a project with a configuration to maintain.

A Custom Tool is a lighter path. Instead of building an app, you describe an action, such as "look up an order," "create a Jira issue," or "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 conversation, passes the right parameters, and reasons over what comes back. There's no code, and the same setup works if you also run Zendesk, Freshdesk, Gorgias, Front, HubSpot or Intercom.

The difference in practice is control and portability. A Custom Tool does exactly what you describe, scoped to the one job you need, and it isn't locked to a single vendor's action framework.

How do you build a Custom Tool in three steps?

Every Custom Tool follows the same shape, whether it's wrapping Salesforce, a Postgres database, or an internal microservice.

1. Point it at the API. You give Macha the endpoint, method, and credentials. If you'd rather not fill in a form, the built-in Sidekick will scaffold the whole thing from a plain-English description, such as "connect Stripe to look up payments" or "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 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 are safe lookups; Writes such as refunds, status changes and record updates require confirmation before they run. Authentication, static headers, and response mapping are all here too, so a real production endpoint drops straight in.

3. The agent uses it live. Once the tool exists, your agent calls it mid-conversation. A customer asks "where's my order?" in Intercom Messenger; the agent recognizes the intent, calls Get Order Status with the order ID it pulled from the chat, and answers with the real status and tracking, grounded in your system of record rather than a guess.

That's the entire loop: define once, and the AI decides when to use it on every relevant conversation 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) with a confirmation step. That boundary is enforced per tool and per agent.

How do Custom Tools handle Read vs Write, auth, and safety?

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

• Read vs Write. Read tools are free to call. Write tools (anything that changes state) require confirmation, so an agent can't silently issue a refund or delete a record.
• Scoped by design. A tool exposes exactly one action against one endpoint. It does the job you defined and nothing else.
• Permissioned per agent. You decide which agents get which tools. Your triage agent might only read; a senior-support agent might be allowed to write.
• Audited. Every call is logged, so you can see exactly what ran, with what inputs, and when.

For authentication, the builder supports the common patterns (API keys, bearer tokens, custom headers), so tools that need credentials work without exposing secrets in the conversation.

When should you use an App Store app, a Data connector, or a Custom Tool?

Custom Tools don't make Intercom's App Store or Data connectors obsolete; they cover what's slow or missing.

• Reach for an App Store integration when a well-maintained one already exists and does what you need out of the box. If Macha has a native connector for the tool, use that instead; it needs no setup beyond signing in.
• Reach for a native Data connector when your team wants everything inside Intercom's own framework and has the time to configure the response shaping and customer authentication it requires.
• Reach for a Custom Tool when there's no app, you want it live in minutes, the tool is internal or industry-specific, or you run more than one help desk and want the same action everywhere.

Portability matters more in 2026 than it did. Salesforce completed its acquisition of Fin, the company formerly called Intercom, on 10 September 2026. If your roadmap could change help desks, an action defined outside any one vendor's framework moves with you.

The honest rule of thumb: if you've ever said "I wish Fin 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 conversation.
• Databases and warehouses: query orders, subscriptions, or usage from Postgres, Snowflake, or BigQuery to answer from source of truth.
• Billing and 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, more than 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 Zendesk, Freshdesk, Front, Gorgias and HubSpot. Custom Tools are portable across all of them.

A missing App Store integration used to mean "not supported," and a native API action meant a configuration project. With Custom Tools, you describe the action, point it at the API, and your Intercom AI agents can read and write it live inside a conversation, with Read/Write guardrails, per-agent permissions, and a full audit trail.

You also don't have to build the tools yourself. Macha is the done-for-you option: the Macha team analyzes your past tickets, builds and tests the Custom Tools, the knowledge base and the agent on your Intercom, and runs it in safe mode, with drafts as internal notes, until the drafts are right. That's included on the trial and every plan at about $0.40 a ticket, which includes setup and a dedicated success manager who handles your changes, such as a new internal API to connect.

Ready to try it? See how Custom Tools work, browse the integration directory, or start a free trial and wire up your first tool today.

Frequently asked questions

Do I need an engineer to build a Custom Tool for Intercom? No. The Macha team builds and tests your Custom Tools for you as part of setup, included on the trial and every plan. If you'd rather build one yourself, you describe the integration in plain English and Macha's Sidekick scaffolds the request, authentication, and parameters. Technical teams can still go deeper with full control over methods, headers, bodies, and response mapping.

How is this different from Intercom's Data connectors (Custom Actions)? Data connectors are Intercom's native way to give Fin an API action inside Intercom, set up in four phases: API, data, Fin and security. Custom Tools are a no-code alternative that works the same way across every help desk you run, so you're not rebuilding the integration per platform.

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

Can it change data, or only read it? Both. Read tools are safe lookups; Write tools (refunds, updates, status changes) require a confirmation step before they run, and you control which agents can use them.

Is it secure? Yes. Custom Tools are scoped to a single action, permissioned per agent, and every call is audited, so you always know what ran, with what inputs, and when.