One API layer, so your systems stop talking point to point.
Point-to-point integrations are cheap to build and expensive to own: every system you add multiplies the connections, and nobody can say what breaks when one goes down. Three named layers put a change in one place instead of six — and the Exchange portal is documented well enough that your team adds the next API without calling us.
- Shape
- Fixed-scope project
- Typical length
- 8–16 weeks
- Priced
- Per layer, scoped from the audit
- Starts with
- A connection audit
- You keep
- Anypoint repo, API specs, policies, dashboards, runbook
Sixteen weeks, three layers, one handover.
Drawn to scaleWhat the integration layer covers.
Four areasThe audit decides how much of this you need. Most orgs turn out to need three system APIs and two process APIs, not the twelve they were bracing for.
The three layers
We design, build and document all three, so your team can add the fourth API without calling us.
| Layer | What lives there | Why it is separate |
|---|---|---|
| System APIs | One per source of record — Salesforce, ERP, HCM | Nothing business-specific, so they outlive the processes on top of them |
| Process APIs | Order-to-cash, lead-to-quote, the business logic | Composed from the system layer rather than wired to it |
| Experience APIs | Shaped per consumer — mobile app, partner portal, the org | A consumer’s needs change without touching the system below |
The connection audit
Every engagement opens with one, and it is usually the first honest map anyone has had:
- Every system — including the ones that only exist in a spreadsheet somebody maintains
- Every existing integration — middleware, scheduled jobs, hand-written Apex callouts, and the nightly CSV
- What each one actually moves — objects, volume, direction, and how fresh it has to be
- What breaks when it stops — the dependency nobody documented
Salesforce-specific patterns
- Platform Events — publish-subscribe between the org and Anypoint, so integrations stop polling
- Change Data Capture — the org tells the integration layer what changed, rather than being asked
- Bulk API 2.0 — for volume, with governor limits respected by design rather than discovered
- External Objects — reading a system of record without copying it into Salesforce at all
Operations and handover
An integration layer nobody can operate is a liability, so the last phase is the one that makes it yours:
- Exchange portal — every API published with its spec and worked examples
- API policies — rate limiting, client ID enforcement, and OAuth applied at the gateway
- Anypoint Monitoring — dashboards and alerts per API, plus dead-letter queues for what fails
- Runbook — how it deploys, what fails first, and what to check at 2am
You keep the Anypoint repository, the API specifications, the policies, the dashboards and the runbook.
The handover
What you are left holding.
An API layer nobody can maintain is six point-to-point integrations wearing a suit. These four are what make it maintainable by your team rather than by ours.
- The Anypoint repositoryEvery flow, every DataWeave transform, every policy — in your git, under your own Anypoint tenancy.
- The Exchange portalSpecs, examples and a working sandbox for each API, so the next team adds one without calling us.
- The monitoringAnypoint dashboards, alert thresholds and dead-letter queues wired before handover, not after the first outage.
- The runbookHow it deploys, what fails first, and what to do when a downstream system goes quiet.