CRM & API integrations
CRM and API integrations that move the right information between teams and tools. Build around clear ownership, permissions and a recoverable path when something fails.
Illustration: an example event in code beside the CRM record it updates. Each event field fills its matching record field, one field shows its precedence rule and the record reads as synced.
A CRM integration often begins with a request to make two dashboards agree. The important question is which system creates a contact, owns an address change and records the customer's permission. We trace the journey from a submitted event to the person who acts on it. This work fits when duplicate entry, delayed handoffs or inconsistent status is affecting real operations, and the systems provide suitable interfaces and access.
Repeated submissions, invalid contact details and an unavailable owner each need a distinct state, not a duplicate record.
View Lead capture & follow-upA storefront may accept an order while stock is stale or the accounting record arrives twice.
View Ecommerce integrationsTwo systems show different states for the same customer, and staff reconcile them by hand.
Describe identifiers, required fields, ownership, consent meaning and access by role before data moves. A field name alone rarely captures a business rule.
Example
| Field | Owning system | Who may change it | When systems disagree |
|---|---|---|---|
| Contact reference | CRM | Created once by the CRM | A reference without a match waits for an operator |
| Email address | CRM | Sales team | The newer update wins |
| Newsletter consent | Email platform | The contact | Stored as recorded, never inferred from other fields |
| Enquiry source | Website form | No one after receipt | Kept for reporting only |
| Order status | Store | Fulfillment team | The store’s state decides |
A project enquiry is not newsletter permission. Consent is mapped only from the system that recorded it, with its meaning intact.
Assign an owner to each product, stock quantity, customer and order state before drawing connections between platforms.
Read the guide: Connecting orders, inventory and CRMThe exact contract depends on the API and business workflow. It names the identifier each event carries, the owner of each field and the agreed next step after each kind of failure.
A timeout means the caller did not receive a result. The other system may already have committed the change. Before retrying a write without duplicate protection, look up the original business record or reconcile the destination state.
Event from the website form contact.updated
{ "event_id": "evt_8841", "type": "contact.updated", "source": "website_form", "contact_ref": "C-1047", "consent": "newsletter", "updated_at": "2026-10-02T09:14Z"}The event was recorded, queued and written once. Each state is shown on its own, so a quick response is not mistaken for a finished update.
The same event arrives a second time.
The receiver already holds this event_id, so the second delivery changes nothing and the CRM keeps one contact.
The CRM commits the write, but its reply never arrives.
The outcome was unknown, not failed. Before any retry the CRM record is looked up; the update is already there, so nothing is written again.
Another event arrives with a contact_ref the CRM does not know.
The record waits in the operator list with the field to correct. It is not retried until someone fixes the reference or returns it to the owning team.
Try a failure
Inspect a field
event_idcontact_refconsentupdated_atBuild bounded requests, idempotent updates where possible and a way to compare source and destination after a partial failure.
Show staff where rejected records appear, what can be corrected and when a decision needs to return to the owning team.
View Automation maintenanceWe choose a representative record and follow creation, update, failure and correction across the boundary. We distinguish accepted, queued and completed work. This avoids treating a successful HTTP response as proof that a person received the right information.
The event is validated and stored with its identifier before the sender is told it arrived.
Processing is separated from receipt, so a slow CRM does not keep the sender waiting.
The record is matched on its identifier and updated once. A repeated event changes nothing.
The responsible person is told after the record is dependable, so a failed message does not create the record again.
The business action has finished in the receiving system; a success response alone is not completion.
Your team confirms what the resulting status means to sales or support, while technical checks confirm what the interfaces actually returned.
An old record, an edited address or a reversed order may be valid in one system and stale in another. We agree precedence and conflict resolution rather than silently overwriting it. API limits, vendor terms, paid access, historical cleanup and personal-data retention are assessed in the actual provider environment. The integration cannot guarantee delivery when a provider is down; the recovery path is part of the design.
Whichever system writes last wins, and a valid newer value disappears without anyone noticing.
Each field has an owner and a conflict rule, so an older update cannot overwrite a newer value.
A small change to a form, CRM schema or permission may affect the exchange, so change review is part of continued operation. Any support term or new integration remains a separate agreement.
Some of the teams we have worked with.
Across talent, fitness, mobility, payments and local commerce.Historical deduplication and data quality require their own rules and review. We can identify the needed work while defining the exchange, but we will not silently merge people or organizations on a weak match.
We use stable identifiers and test what the destination does when the same request arrives again. Where idempotency is unavailable, the workflow needs a reconciliation step before another write.
No. We start from a representative record and the interfaces your systems document. Credentials and customer data belong in an approved secure channel, never in an initial enquiry.
Continue exploring
Tell us where it starts, which systems should agree and what staff fix by hand. We can trace it to completion and define the contract around it.