Integration guides
Implementation depth for the systems you already run.
Per-platform guides covering object model, authentication, rate limits, and the specific failure modes of connecting each system into a governed workflow.
Per-platform
Written for the system, not generically
By category
Shared constraints grouped by system type
Failure-first
The exception path covered explicitly
Introduction
How these differ from the connector pages.
The connector pages cover connections where we can state the full chain from authorised through to a usable outcome. These guides are broader and deeper on implementation: what a platform’s object model looks like, how its authentication behaves, and which of its constraints will shape your design.
They are grouped by category because most of the hard constraints are category constraints. A CRM has ownership and duplicate semantics a support desk does not; a ledger has period-close rules a chat tool does not.
- Organised by
- Category, then platform
- Depth
- Implementation detail
- Assumes
- The platform stays authoritative
- Related
- Workflow blueprints
Why this exists
Generic integration advice does not survive contact with a specific API.
Every integration guide that applies to all systems equally is describing the parts that were never difficult. The parts that break a design are specific: how a platform meters its API, whether it emits change notifications or requires polling, whether it can express field-level permissions at all.
The other reason for per-platform depth is that the failure modes are unevenly distributed. A retried write is catastrophic against a ledger and harmless against a notification surface, and a design that treats them the same will get one wrong.
You're likely here because
- A connection works and the data is not trustworthy
- Rate limits are being discovered in production
- Nobody checked whether the platform can express the permissions you assumed
How to choose
Finding the right guide.
If
You know the platform
Start with
Find it in the category listing below
If
You know the category but not the platform
Start with
Open the category hub and compare within it
If
You know both systems in a handoff
Start with
The workflow blueprintsIf
You want the connections we can vouch for end to end
Start with
The live connector pagesHow it works
What every guide covers.
The platform changes; these five questions do not.
Step 01
What it owns
Which records the platform is normally authoritative for, and therefore what should not be written elsewhere.
Step 02
What it emits
The events worth triggering work from, and how delivery behaves — ordering, retries, and duplicates.
Step 03
What it accepts
Which writes are safe, which need approval, and where field-level authority can actually be enforced.
Step 04
How it fails
The category-specific failure mode, from duplicate creation to period-close violations to update loops.
Step 05
How it is measured
What completion looks like for workflows built on it, and which exceptions matter.
Categories
Guides by category — 126 in total.
Productivity
17 guides — read the productivity overview →Engineering
18 guides — read the engineering overview →Scope
Limits of these guides.
- They do not replace provider documentation for API specifics.
- Availability depends on your provider configuration, scopes, and deployment state.
- Self-hosted instances may expose a different surface than cloud versions.
- A guide existing does not mean every capability of that platform is exposed.
FAQ
Questions about this collection.
How is a guide different from a connector page?
A connector page covers a connection we can state the full chain for, from authorised through to a usable outcome. A guide covers implementation depth for a platform, whether or not that chain is published.
My platform is not listed.
The category page is usually the right starting point — most of the binding constraints are category constraints rather than vendor ones.
Do we have to replace the platform?
No. Every guide assumes it stays authoritative for the records it already owns.
Are rate limits something you can work around?
No. They are provider-enforced. What a design can do is batch, back off, and use bulk paths where the provider offers them.
How current are these?
The category constraints are durable; specific API details change. Verify anything version-specific against provider documentation.
Where should implementation actually start?
With the workflow rather than the connector. Which handoff needs to work determines which connection matters.
Start with ARIA
Ask ARIA about integration guides.
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.
- You can change or revoke any connection at any time.
- Every action is recorded, and anything significant can require your approval first.
Start here
Start from the workflow, not the platform.
Describe the handoff you need. ARIA resolves which platforms have to participate and which of their constraints will shape the design.