Integration Connection Status: Keeping AI-Agent Connectors Healthy, Tested & Reconnected
An AI agent is only as reliable as the tools behind it. The moment a Shopify API key is rotated, a Zendesk OAuth grant is revoked, or an Atlassian token quietly expires, every agent that depends on that connector starts failing — and the worst failures are the silent ones. The agent keeps trying, the customer keeps waiting, and nobody finds out until a backlog has already formed.
Most "integration connection status" guides are written for humans clicking around a SaaS dashboard — Zapier telling you a Zap is "Not authenticated," Atlassian's "connection test failed," Microsoft's token-expiry errors. The stakes are different when the thing depending on that connection is an autonomous AI agent acting on live tickets. This post is about that case: how Macha tracks each connector's health, how you confirm a connection works on demand, and how you reconnect a broken one without breaking the agents built on top of it.
This is the unglamorous half of running agents in production, and it's exactly what Macha's connector health system exists to handle. Shipped in the April 23, 2026 release, it gives every connector a tracked health status, a one-click way to test credentials, a validated reconnect flow, and — critically — automatic containment when authentication breaks, so a dead integration takes down the affected agents quietly and safely instead of silently spraying errors at your customers.
Macha is an agent layer that sits on top of your helpdesk and connects your commerce, knowledge, and comms tools. That means connector health isn't a nice-to-have — it's load-bearing. Here's how it works.
Why connector health is the failure mode that matters
Every team that runs OAuth integrations eventually meets the same wall. Microsoft and Google refresh tokens expire after extended inactivity or a password change; a user revokes access; an API key gets rotated during a security review. Make's community forum is full of "connection expires every 7 days, please reauthorize" threads, and the standard production answer — documented by token-infrastructure vendors like Nango and Scalekit — is always the same shape: validate credentials proactively, run periodic health checks, mark a broken connection as unhealthy / needs_reconnect, and alert a human instead of retrying into the void.
Macha implements exactly that pattern. The difference is that here the "thing that breaks" is an autonomous agent acting on live tickets, so the cost of a silent failure is higher than a broken Zapier zap — and the containment has to be smarter than just logging an error.
Integration connection status: every connector has a health state
The foundation is the connection status itself. Each connector now carries a state — connected or auth_failed — that Macha maintains automatically based on how the tool's API actually responds. You don't poll it manually; it reflects reality. (If you're new to how connectors, tools, and triggers fit together, the connectors, tools and triggers explainer is the place to start.)
The important behavior is what happens on the transition from connected to auth_failed. When authentication breaks, Macha doesn't just flip a badge and hope someone notices. It does two things immediately:
- Affected agents are automatically deactivated. Any agent that depends on the broken connector is paused. This is the containment step that matters most — a deactivated agent stops cleanly instead of attempting tool calls that will 401, fail mid-conversation, or leave a customer hanging on a half-finished action.
- Admins are notified by email. The people who can actually fix it get told, with a direct path to the reconnect flow, rather than discovering the outage from an angry customer two days later.
That "deactivate, then notify" ordering is deliberate. It treats a broken connector as a safety problem first and an operational one second. The same philosophy shows up in the Confluence connector, which lets you enter your Atlassian API token's expiry date so Macha can email reminders 30 days before it lapses — and auto-deactivates the connector on a 401 if it slips through (we cover that in connecting Confluence with token-expiry monitoring). Health monitoring is most valuable when it's proactive: the best outage is the one you reconnect before it happens.
Test connection: verify credentials in one click
Status tracking tells you when something has broken. Test connection lets you check on demand — before you build an agent on top of a connector, after you rotate a key, or while you're debugging why a tool call failed.
It does what it says: one click validates the stored credentials against the real API and tells you whether they work. It's available for all connector types, OAuth and API-key alike, which matters because the failure modes differ. An OAuth connector might have a revoked grant; an API-key connector might have a key that was rotated or scoped wrong. A single, uniform "does this actually authenticate right now?" check covers both.
In practice, Test connection is the thing you reach for whenever you're not sure who's at fault. Tool call returning nothing? Test the connection first. If it passes, the problem is your agent's instructions or the tool's arguments; if it fails, you've found your culprit in two seconds instead of reading logs.
The result is unambiguous: a verified connection returns a green confirmation (here it even echoes back a live API response — the Stripe account balance — proving the credentials didn't just exist but actually worked), while a broken one returns a failure you can act on immediately.
Reconnect: fix it without breaking your agents
Finding a broken connector is half the job. Fixing it cleanly is the other half — and "cleanly" is doing a lot of work in that sentence. The naive approach is to delete the connector and re-add it, but that detaches every tool, strips the connector ID your agents reference, and forces you to rebuild each agent's tool list by hand. Macha's reconnect flow is built specifically to avoid that.
How you reconnect depends on the connector's auth type:
- API-key connectors (Stripe, Shopify, Gorgias, Freshdesk, Razorpay, Cal.com, ElevenLabs, Tavily, and the rest) show a reconnect form when auth fails. You paste the new key, and Macha validates the credentials before saving — so you can't accidentally "fix" a connector with a key that's also wrong. The save only succeeds once the credentials actually authenticate.
- OAuth connectors (Zendesk, Google Workspace, Slack, Notion) get a Reconnect button that re-authenticates in place. Same connector ID, no tool stripping, no agent breakage — you re-grant access and the existing agents pick up right where they left off. A dedicated email template points admins straight at this flow when a connector goes down. (The OAuth grant itself is the same one you set up in connecting Zendesk to Macha over OAuth — reconnect simply re-runs that consent step against the existing connector.)
The "validate before save" detail is the quiet hero here. Reconnect flows that accept whatever you type and only fail on the next tool call turn a five-minute fix into a frustrating loop. Validating at the point of save means that once the form accepts your credentials, the connector is genuinely healthy again — and the agents Macha deactivated can be turned back on with confidence.
Under the hood: defense in depth against the messy cases
Two more pieces of the April 23 release aren't buttons you click — they're the plumbing that keeps health status honest when the real world gets messy.
Webhook rejection tracking. When a connector is broken, the external system (Zendesk, Shopify) often keeps firing webhooks at Macha that can't be processed. Rather than absorb them forever, Macha tracks rejected webhooks and, after a configurable threshold on a broken connector, returns a 410 Gone — the HTTP status that explicitly tells a well-behaved external system to stop sending. This is the same backpressure pattern that resolves the cascading-retry problem, where a downstream outage gets amplified by upstream systems hammering a dead endpoint.
Refresh-lock utility. OAuth tokens expire and have to be refreshed, and the dangerous moment is when two requests try to refresh the same token at once — a classic race condition where one refresh invalidates the other's token mid-flight. Macha uses a shared refresh-lock (single-flight) utility across its OAuth connectors — Zendesk, Google, Shopify — so only one refresh runs at a time and the others wait for the result. This isn't theoretical: a concurrent-refresh race once caused a real customer outage (two webhooks racing on a single-process Node server), and the fix was compare-before-write logic plus this shared lock. Single-flight refresh is precisely the protection that production token-handling guides recommend, and it's why your connectors don't randomly drop auth under load.
Together these mean the health status you see is trustworthy: connectors don't flap into auth_failed because of a self-inflicted race, and broken connectors don't generate infinite downstream noise.
How it maps across your connectors
Different tools authenticate differently, so the health story varies slightly by connector. Here's the practical version:
| Connector | Auth type | How it breaks | How you fix it |
|---|---|---|---|
| Zendesk, Google Workspace, Slack, Notion | OAuth | Grant revoked, refresh-token expiry | Reconnect button — re-auth in place, same connector ID |
| Shopify, Stripe, Gorgias, Freshdesk, Razorpay | API key / token | Key rotated, scope changed | Reconnect form — paste new key, validated before save |
| Confluence | API token | Token expiry | Expiry-date reminder (30 days out) + reconnect; 401 auto-deactivates |
| Front, Airtable, Cal.com, ElevenLabs, Tavily | API token / PAT | Token revoked or rotated | Reconnect form — validated before save |
| File Tools | None | n/a — no credentials | n/a |
Whatever the connector, the loop is the same: status flips to auth_failed → affected agents deactivate → you get an email → Test connection confirms the problem → Reconnect fixes it (validated) → reactivate. (For the full per-connector setup details, see the integrations directory and the docs.)
Watch-outs — where this helps and where it doesn't
Connector health is containment and recovery, not magic. A few honest limits:
- It doesn't prevent the break. Macha can't stop someone from revoking an OAuth grant or rotating a key without telling you. What it does is catch the break fast, contain the blast radius, and make the fix a two-minute job. The Confluence-style expiry reminders are the closest thing to prevention, and they only work if you enter the expiry date.
- Reactivation is a human decision. When a connector recovers, the agents Macha deactivated don't silently turn themselves back on. That's intentional — you may want to verify the fix first — but it means reconnecting is two steps: fix the connector, then re-enable the agents.
auth_failedis binary, not granular. The status tells you authentication is broken; it doesn't diagnose why (revoked vs. rotated vs. scope) or surface partial outages where some tools work and others don't. Test connection plus the tool-level error banners in conversation history fill that gap.- Webhook backpressure is a blunt instrument. Returning
410 Gonetells the external system to stop sending — which is correct for a genuinely dead connector, but it means once you reconnect you may need to re-register or re-enable the webhook on the source system's side, depending on how it handles a 410.
None of these are reasons to avoid the feature — they're the operating manual for using it well. The point of connector health isn't to pretend integrations never break; it's to make the inevitable break boring.
FAQ
What's the difference between connected and auth_failed? connected means the connector's stored credentials authenticate successfully against the tool's API. auth_failed means they don't — typically a revoked OAuth grant, an expired refresh token, or a rotated API key. On the transition to auth_failed, Macha deactivates the affected agents and emails your admins.
Does a broken connector break my agents mid-conversation? No — that's the point of auto-deactivation. When a connector fails auth, the agents that depend on it are paused so they stop cleanly instead of attempting tool calls that will fail. You reconnect, then re-enable them.
How do I check whether a connector is working right now? Use Test connection. One click validates the stored credentials against the live API for any connector type, OAuth or API-key. It's the fastest way to tell whether a problem is the connection or the agent.
Will reconnecting break my agents' tools? No. The reconnect flow is built to preserve the connector ID and credential fields — OAuth connectors re-auth in place, and API-key connectors validate the new key before saving. Your agents' tool lists stay intact.
Does connector health monitoring cost credits? No. Credits are spent on AI actions (per message, by model — default GPT-5.4 Mini is 1 credit), not on health checks, status tracking, or reconnects. See the pricing page for how credits work.
Try it
The fastest way to understand connector health is to connect a tool and watch the status track it. Start a 7-day free trial, no credit card required, connect Zendesk or Shopify, and build an agent — then read the integrations directory for the per-connector setup and the docs for the full reconnect walkthrough. The goal is simple: when an integration eventually breaks, you find out from an email, not a customer.
Written by Abbas (Customer Support & AI, Macha) · Reviewed by Ankeet Guha (Co-founder & CTO) · Published 2026-06-24 · Last updated 2026-06-24.
Resolve tickets automatically with AI agents
Macha's AI agents work on top of the help desk you already use — no code.
Shopify
Stripe
Slack
Notion
Google Workspace
Confluence

