Connector categories
The constraints that apply to a whole category, not one vendor.
Most of what shapes an integration is a category property: a CRM has ownership and duplicate semantics a chat tool does not; a ledger has period-close rules a support desk does not. Designing against those properties is what makes an integration survive the vendor being replaced.
Category-level
Constraints that hold across vendors
Design-first
What to decide before choosing a platform
Vendor-neutral
Applies whichever product you run
Introduction
Why category is the more useful unit.
Teams usually start from a vendor name, but the decisions that determine whether an integration survives are category decisions: what the system is authoritative for, what it emits that is worth acting on, and which failure mode it produces under load. The vendor determines the API shape. The category determines the design.
Getting those right transfers if you later change vendor within the category — the workflow gets repointed rather than rebuilt. Getting them wrong is expensive regardless of which product you picked, because the cost lands in the workflow rather than in the connector.
The useful test is to describe your integration without naming the product. If the description still makes sense — this system owns the customer record, it emits an event when the stage changes, it accepts a write on the activity object — you have designed against the category. If it collapses into a list of endpoint names, you have designed against a vendor, and the next migration will start from scratch.
That is also why these pages sit above the per-platform guides rather than beside them. A category page is meant to be read once per category and then reused across every integration you build in it; a platform guide is meant to be read once per implementation.
- Unit
- System category
- Applies to
- Any vendor in the category
- Deeper
- Per-platform guides
- Narrower
- Live connector pages
Why this exists
Vendor-first integration design does not survive a vendor change.
An integration designed around one product’s quirks encodes those quirks everywhere. When the product is replaced — and in most of these categories it eventually is — the workflow has to be rebuilt rather than repointed, and the rebuild is charged to a team that has already moved on to something else.
The second failure is authority drift. Nobody decides which system is authoritative for a shared field, so two of them write it, and the integration becomes a race whose winner varies by sync timing. This is invisible until the day someone reconciles the two and cannot explain the difference.
The third is designing for the happy path of a category whose defining property is a specific failure mode. Ledgers have period close. Support desks have ticket merges. Chat platforms have rate limits and message ordering that is not guaranteed. Each of these breaks a naive integration in a way that reads as a bug in the workflow rather than a property of the category.
Designing against the category constraint instead keeps the vendor-specific part at the edge, which is both cheaper to change and easier to reason about when something goes wrong at two in the morning.
You're likely here because
- A vendor change is plausible within a few years
- The same integration logic is being rewritten per product
- Nobody has decided what the category is authoritative for
- Two systems both write the same field on the same record
How to choose
Where to go from here.
These pages are ordered by how much you have already decided, not by category size.
If
You know which systems participate but not how they should behave
Start with
Pick the category below and read what it owns, emits, and accepts
If
You have chosen the platform and need its specifics
Start with
The per-platform integration guideIf
You want connections we can vouch for end to end
Start with
The live connector pagesIf
You are still deciding what the workflow should do
Start with
Start from a workflow blueprint insteadIf
You need the decisions written down before anyone builds
Start with
The integration specification templateHow it works
What every category page answers.
The same five questions, in the same order, for every category. The order is deliberate: you cannot decide which writes are safe before you have decided what the system is authoritative for.
Step 01
What it owns
The records the category is normally authoritative for, and the fields that other systems should therefore treat as read-only. Getting this wrong is the source of most reconciliation work later.
Step 02
What it emits
The events worth triggering work from, how delivery behaves under load, and whether ordering is guaranteed. A category that emits at-least-once needs idempotent handling downstream.
Step 03
What it accepts
Which writes are safe to automate, which need an approval boundary, and which should never be automated because the category has no way to undo them.
Step 04
How it fails
The category-specific failure mode that shows up regardless of vendor — period close, merge semantics, rate limits, partial sync — and what a workflow should do when it hits one.
Step 05
What to measure
What completion looks like for workflows built on this category, so a run that half-succeeded is visible as a failure rather than reported as a success.
Categories
Connector categories — 8 in total.
Each page covers the constraints that hold across every vendor in that category.
CRM integrations
Connect CRM context to Launch and Grow workflows.
Explore →Email integrations
Connect mailbox context to outreach, replies, and operational workflows.
Explore →Calendar integrations
Keep availability and scheduling inside the same workflow context.
Explore →Marketing integrations
Connect campaign and lead context to downstream revenue workflows.
Explore →Accounting integrations
Use finance-system context in focused operational workflows.
Explore →Support integrations
Connect customer requests and support context to operational workflows.
Explore →Commerce integrations
Connect customer and transaction context to the workflows around revenue.
Explore →Productivity integrations
Connect documents, collaboration, and team context to the operating layer.
Explore →Scope
Limits of category-level guidance.
- Category constraints do not cover vendor-specific API behaviour, quotas, or authentication quirks.
- Availability still depends on your provider configuration and the scopes you granted.
- A category page is a design aid, not an implementation guide — it will not get you to a working connection on its own.
- Where a vendor deliberately breaks the category pattern, the per-platform guide is authoritative and the category page is wrong for that product.
- Nothing here replaces testing against your own data. Category constraints predict the shape of the problem, not its size in your environment.
- These pages describe systems as they behave today; a category’s constraints move when the dominant products in it change their model.
FAQ
Questions about this collection.
Why not just read the vendor guide?
Read both. The category page tells you what to decide; the vendor guide tells you how that platform behaves. Skipping the first is how integrations get rebuilt after a vendor change rather than repointed.
How many categories are there?
Eight, chosen because they have genuinely different authority models and failure modes rather than to fill a grid. A ninth that behaved like one of the existing eight would be a page that made the set look bigger and the guidance no better.
My system spans two categories.
Common — many platforms do. Read both, and decide per record which category’s rules apply to it. The mistake is deciding at the system level, because that forces one set of rules onto records that do not follow them.
Does this replace provider documentation?
No. It is design guidance; the provider remains authoritative on API specifics, limits, and behaviour. Where the two disagree about a specific product, the provider is right.
Do we need UbiVibe for any of this?
No. The category constraints apply to any implementation, in any stack. They describe how these systems behave, not how our runtime behaves.
Where should design actually start?
With the workflow. The category matters once you know which systems have to participate — starting from the connector list produces an integration in search of a job.
Start with ARIA
Ask ARIA about connector categories.
You do not have to pick your way through this collection to get started. Describe the outcome you want and ARIA determines which capabilities, systems, and workflows the job needs.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Design against the category, not the logo.
Describe the handoff you need. ARIA resolves which categories have to participate and which of their constraints will shape the design.