Integration and automation

The connection is easy. Ownership is the job.

Two systems holding the same customer will eventually disagree. Deciding which one wins, field by field, is the part that takes a week and saves a year.

Thirty minutes · no predetermined package

Incoming leadsdefaultChecked on arrivalLIVE
Accepted 0Rejected 0answered in under 200ms, every time
✓
Accept or reject in the same request
the partner knows now, not on Friday
The hard part

Which system wins, field by field.

This table is the integration. Everything after it is typing. Bidirectional sync on a contested field is the most common cause of data corruption in a connected stack.

FieldOwnerAlso holds itRule
Company nameYour CRMPartner feedfirst write wins
Phone numberDialerYour CRMlast verified wins
Deal stageYour CRMPartner feedCRM is the record
ConsentCompliance storeYour CRMnever overwritten
Amount fundedServicing platformYour CRMdownstream is truth
Symptoms

What a missing integration looks like from inside.

01

A recurring calendar reminder exists whose entire purpose is moving data from one system to another.

02

Two systems hold the same customer and disagree, and nobody can say which one is right.

03

A partner sends leads and finds out days later that half were rejected.

04

An integration broke silently, and the first sign was a number that looked wrong at month end.

05

A person exports a file on Friday so that a report is correct on Monday.

06

The same record exists three times because each system decided it was new.

Evaluation

Six questions before anyone writes a connector.

Every one of these has a wrong answer that only shows up in production, months later.

01Which system owns each field when two of them disagree?This is the whole job. Bidirectional sync on a contested field is the most common cause of data corruption.
02What happens to a record that fails validation — rejected, queued, or silently dropped?Silently dropped is the default in most integrations and nobody discovers it for months.
03Is the receiving system idempotent if the same event arrives twice?Retries happen. Without a deduplication key you get duplicate records rather than a duplicate request.
04How does anyone find out the integration stopped?An integration with no alerting is a scheduled job that fails quietly and takes the reporting with it.
05What is the rate limit at the other end, and what happens when you reach it?Backoff and a queue, or a lost record. There is no third option.
06Does a partner learn the outcome in the same request, or hours later?Synchronous accept or reject changes the partner relationship more than any dashboard does.
The sequence

Five stages, and the mapping comes first.

01

Map the fields

the ownership table

Every field, which system owns it, and what happens when they disagree. Signed off before anything is written, because this is the decision the integration is.

02

Validate at the edge

accept or reject

The receiving end decides in-request. A partner knows immediately rather than discovering a rejection days later.

03

Make it idempotent

safe to retry

A deduplication key on every event, so the same record arriving twice creates one record and not two.

04

Instrument it

visible when it breaks

Alerting on failure rate, latency and volume drift. An integration nobody watches is one that has already stopped.

05

Hand over the runbook

operable

What to do when the other end changes, rotates a credential, or starts rate-limiting you.

Build or buy

Custom API integration is not always the answer.

Three options, and we will tell you when the platform is enough.

01Default

Custom API integration

Built against your data model, with your ownership rules and your validation. The only option when the logic is specific to your business.

When the rules are yoursand a wrong record costs real money.
02Considered

An iPaaS platform

Workato, Boomi, Mulesoft. Genuinely good at standard connectors and expensive once the mapping gets specific.

When the connectors existand the mapping is close to default.
03Considered

Zapier or Make

Fine for low volume and simple triggers. The ceiling arrives with error handling, retries and anything conditional.

When volume is lowand a missed record is not a problem.
Where this comes up

The systems change. The ownership question does not.

Lending and financial services

Partner and ISO feeds, bank data, credit signals and servicing platforms that all hold part of the same file.

Home services

Dispatch, financing partners and accounting, where the job record has to reconcile across all three.

Insurance

Carrier portals and rating platforms, most of which have no API at all — which changes the honest answer.

Professional services

Practice management, billing and intake, usually three products from three vendors with one client between them.

Questions

What people ask about API integration.

What is API integration?

API integration connects two systems so that a record created or changed in one appears correctly in the other. The connection is the easy half; deciding which system owns which field when they disagree is the work.

What do API integration services actually include?

Field mapping and ownership rules, validation at the receiving end, deduplication, retry and backoff handling, alerting when it breaks, and a runbook for the day the other end changes without telling you.

How do you manage multiple API integrations efficiently?

One ownership table covering every field across every system, one place errors are surfaced, and idempotency on every write. The failure mode is a separate ad-hoc script per connection with no shared error handling.

How do you integrate multiple CRM systems with a single API?

Choose a system of record per entity, then sync one direction per field. Bidirectional sync on the same field is the most common cause of corruption in multi-CRM environments.

What is idempotency and why does it matter?

An idempotent endpoint produces the same result whether an event arrives once or five times. Networks retry, so without a deduplication key a retry becomes a duplicate customer rather than a duplicate request.

Should we use an iPaaS instead of custom integration?

Use one when the connectors already exist and your mapping is close to default. Build custom when the rules are specific to your business, volume is high, or a wrong record costs real money.

What happens when the other system has no API?

The honest answer is a structured manual step with a named owner, not a fragile scrape. Several carrier and utility portals fall into this category and pretending otherwise creates a system nobody trusts.

How long does an API integration take to build?

The mapping decision takes longer than the code. Expect the ownership table to occupy the first week, and expect it to change what everyone thought the integration was for.

Usually alongside

What this is normally built with.

C
Custom CRM development
when the record itself is wrong
A
Business process automation
once the data moves, the work can
D
Data and reporting
the reason the integration exists