Integration Suites
A collection of automations deployed together, sharing state and coordinating across workflows — the unit customers install when they buy a multi-step integration product.
An integration suite is a set of automations that ship as one product. Each automation runs on its own, but they share state, wait on each other where ordering matters, and run against the same connector connections. The customer installs one thing. Underneath, dozens of automations coordinate.
What a production suite looks like
The integration products APIANT runs internally were hand-built by experienced integrators over months. A few representative examples:
- ShopConnect (Mindbody ↔ Shopify) — 46 automations across master routing, per-site sync flow, admin tools, and integration settings. A shared lock prevents echo loops, identity caches keyed by SKU and email resolve records in O(1), and hash-based change detection lets unchanged records skip the pipeline entirely.
- CRMConnect (Mindbody → HubSpot) — 58 automations covering the production sync flow plus master routing, per-site customizations, admin tools, and integration settings. Syncs clients, appointments, sales, memberships, contracts, class bookings, and visits into HubSpot. Identity caches resolve a Mindbody client to a HubSpot contact in O(1) on every subsequent run; pricing and service context that took a chain of API calls to gather gets cached under multiple composite keys so deal creation later in the suite is instant.
- ZoomConnect (Mindbody ↔ Zoom) — 58 automations across class meeting sync, appointment-class sync, SMS notifications, master routing, and integration settings. Coordinates the full meeting lifecycle: creation, client registration, email notifications, attendee tracking, recording distribution. Multi-trigger automations, cross-automation dispatch, calendar-invite generation, and conditional email-section composition all coordinate through suite-level shared state.
These are customer-facing products running at scale — see the full Mindbody integration catalog. Each one took experienced integrators months of work to ship the first time.
What changes when Claude builds the suite
A suite of this complexity used to be months of work for an experienced specialist. Claude does it in days.
You brief Claude the way you'd brief a senior integrator — what triggers fire, where data moves, what state has to persist between runs, what runs first, what waits on what. Claude lays the suite out: separate automations, a shared lookup-table namespace, protocol threads where ordering matters, connector connections set up once and reused everywhere.
"Build me a two-way sync between system A and system B. On conflict, A wins. Cache identity by email. Emit a change notification when a record older than 24 hours gets updated."
You spend your time on the parts that need a human: deciding what the integration should do, reviewing what Claude built, and shipping it.
How it differs from a single automation
| Single automation | Integration suite | |
|---|---|---|
| Scope | One workflow | A coordinated product |
| State sharing | Just its own storage | Shared namespace across automations |
| Cross-automation timing | None | Protocol threads — one waits on another |
| Connector instance reuse | One per automation | Same connector instance reused across automations in the suite |
| Deployment | Standalone | One package, installed together |
Building one
Ask Claude to build the integration. Claude scopes the work, decides what gets built first, then builds each automation in the suite. See Build an integration suite for the walkthrough.
See also
- Data Storage — the shared state that lets a suite coordinate
- Build with the Plugin — building integrations, custom connectors, automations, and forms