Two-way record sync
Accounts, contacts, orders and inventory moving both ways between your product and a system of record, with per-field ownership, conflict rules, and a defined answer for what a delete means.
Field mapping with ownersSystems plumbing
Systems that stop disagreeing about the same record
We plumb your product into the systems that already run the business — CRM, ERP, payments, partner feeds — so one record means one thing, and duplicate webhooks change nothing.
- Fixed scope per seam
- Sandbox spike first
- Replay and reconciliation
- 30-day warranty
Where integrations actually break
Connecting to an API is an afternoon. Authenticate, call an endpoint, parse the response, and the demo works. The project is everything after that: the four hundredth record that trips a validation rule nobody documented, the rate limit that only appears during a month-end run, the webhook that arrives twice, and the record someone deleted on the other side while your job was halfway through it.
The hardest meeting on an integration project is not technical. It is the one where operations, finance and sales sit down and decide which system owns the customer’s address, what happens when both sides edit it in the same minute, and whether a delete on one side means a delete on the other. Left unsettled, the pipe still ships and both systems quietly drift apart until someone downstream notices the numbers do not match. We force the decision in writing before any pipe is built, and we do not cut over until reconciliation agrees twice.
| What is true of this work | What it forces | What we do about it |
|---|---|---|
| No transaction spans the boundary | Every write must be replayable | Idempotency keys, stored raw payloads |
| Delivery is at-least-once at best | Duplicates must be harmless | Dedupe by event id |
| Rate limits are shared org-wide | Your sync can starve reporting | Per-seam budget, client-side backoff |
| Both sides can edit a field | Someone must own each field | Written conflict rules, signed pre-build |
| Provider docs describe intended behaviour | Tests against docs pass falsely | Fixtures recorded from live sandbox |
In scope
- Seam design, build and cutover
- Field mapping and conflict rules
- Replay console and dead-letter queue
- Nightly reconciliation and drift reporting
Not in scope
- Cleansing the data you already hold
- Rebuilding the legacy system behind a seam
- Ongoing on-call once warranty ends
Handled by
- Data ModernizationDeduplication, schema repair and data quality work
- Maintenance & SupportMonitoring, on-call and version migrations after the warranty
What we build
Payment and billing seams
Checkout, subscriptions, invoices and refunds wired so a retried request cannot charge twice. Money paths get uniqueness constraints in the database, not a check in application code.
Idempotent write handlersInbound event gateway
One front door for every provider that calls you: signature verified, raw payload stored before parsing, deduplicated by event id, then handed to a handler you can re-run months later.
Deduplicated event logLegacy and batch seams
SOAP endpoints, EDI documents, fixed-width files landing on SFTP at 2am, and views someone exposed a decade ago — wrapped into the same event shape as modern APIs.
SFTP and EDI adaptersAgent-safe tool surface
The same integrations exposed to agents as narrow, named tools with scoped credentials, per-call limits and an approval gate on writes. An agent gets ‘create quote’, never a CRM key.
Scoped tool definitionsReconciliation and drift control
A scheduled job that compares both sides record by record and reports what disagrees, because a sync with no errors in the log is not a sync that is correct.
Nightly drift reportHow the work runs
- 01Weeks 1–2
Inventory and spike
We list every connection point, get working sandbox credentials, and record auth model, rate budget and delta support for each. Then we write throwaway code against the hardest seam and try to break it.
You getIntegration register, spike report, per-seam price
- 02Week 3
Ownership mapping
We map field to field and force a decision on each: which system owns it, what happens when both change it in the same minute, whether a delete propagates. Your operations lead signs it.
You getSigned field mapping and conflict rules
- 03Weeks 4–9
Build with replay
We build the pipe: idempotent handlers, stored raw payloads, exponential backoff with jitter, a dead-letter queue, and a console your team uses to replay a failed batch without calling us. Contract tests run against recorded fixtures.
You getRunning sync with replay console
- 04Weeks 10–12
Backfill and cutover
We backfill history, then run the old process and the new sync in parallel until the nightly reconciliation comes back clean twice, and cut over. You keep the drift dashboard, the runbook and a 30-day warranty.
You getReconciliation report and cutover runbook
What you are handed
- Integration register with per-seam rate budgets
- Field mapping with owner of truth
- Idempotent handlers and stored raw payloads
- Dead-letter queue with replay console
- Nightly reconciliation job and drift report
- Contract tests pinned to provider versions
- Recorded sandbox fixtures for every seam
- Credential rotation runbook, keys in your vault
- Runbook for the three likeliest failures
Typical stack
Connectivity
REST, GraphQL and OData clientsSOAP and WSDL toolingEDI X12 and EDIFACTSFTP and fixed-width parsersOAuth 2.0, JWT, mTLSHMAC webhook verification
Systems
Salesforce REST, Bulk and Platform EventsSAP OData, IDoc and BAPIStripe and billing ledgersNetSuite, Dynamics 365, HubSpotShopify, Xero, QuickBooks
Movement
Celery and Temporal workflowsPostgres queues with SKIP LOCKEDKafka or NATS for fan-outDebezium change data captureAirbyte for bulk loads
Assurance
Pact contract testsRecorded sandbox fixturesVault and AWS Secrets ManagerOpenTelemetry, Grafana, SentryTerraform for every environment
The calls we make, and why
Should we buy an integration platform instead of building this?
Buy for the long tail, build the seams that carry money
A platform earns its subscription when you need many shallow connectors fast and nobody wants to watch changelogs. We build in your repo when the logic is genuinely yours — custom objects, unusual conflict rules, money paths, or a sync your customers complain about by name.
We’d choose otherwise whenintegrations are a checklist item for procurement and no seam touches money or customer-facing state
Webhooks or polling?
Both. Webhooks for latency, a delta pull as the net
Webhooks are at-least-once at best: providers drop them during incidents, deliver them out of order, and retry ones you already handled. Polling alone is honest but burns rate budget and lags. Running both costs one extra scheduled job and removes a whole class of silent data loss.
We’d choose otherwise whenthe source has no event feed at all and an hour of staleness costs nothing
Do we copy the data into our database, or read it live?
Copy anything you filter, join, or show in a list
Reading live puts your page load behind someone else’s rate limit and their next outage, and you cannot index their API. We read through only for data that must be current to the second, or that you are not allowed to store.
We’d choose otherwise whenthe value is a checkout price, a credit decision, or a record residency rules forbid you storing
Can our agents just call Salesforce directly?
No. Agents get narrow tools, never a broad API key
An agent handed a broad key will page through more records than any human would, retry on ambiguity, and create the same opportunity three times. We put agents behind the same layer as everything else: per-call quotas, layer-generated idempotency keys, approval on writes.
We’d choose otherwise whenthe agent only reads, the data is not confidential, and the quota is genuinely its own
This fits if
- Finance reconciles two systems in a spreadsheet every month
- Your product must connect to whichever CRM each customer already runs
- An acquisition has left you with two systems of record
- Staff re-key the same order into three tools and one silently drifts
- You want agents writing into a CRM without anyone losing sleep
Look elsewhere if
- A supported native connector already exists — install it instead
- A frozen nightly CSV drop — a scheduled script is cheaper
- Nobody internally can grant sandbox access or settle field ownership
EngagementFixed scope per seam
Typical length5–12 weeks
How it startsSend us one record that is wrong in both systems, plus sandbox access to each.
Questions we get asked
What actually drives the cost of an integration project?
The shape of the other system’s API, not the number of systems. A provider with delta queries, real webhooks, a generous rate limit and a sandbox that matches production is a week. One with no change feed, a nightly export and undocumented validation rules is a month for the same outcome. We price each seam separately after the spike.
Who owns the code, the credentials and the connections?
You do, all of it, transferred outright on final payment with no licence back to us. Credentials live in your secret manager from day one and are issued by your administrators, never held in ours. If you later replace us, or move to an integration platform, nothing has to be extracted from an account we control.
What happens when the provider changes or retires their API?
Your contract tests fail in CI before production does. Every call is pinned to an explicit API version, tests run against recorded fixtures, and the register lists each provider’s deprecation policy and dates. It will happen, so we build for it rather than promise it will not. Migrations after the warranty are quoted as work, not absorbed silently.
Our data is already messy. Does that break the project?
It does not break it, but dirty data is where integration budgets overrun most often, so we surface it in week one rather than month three. The spike pulls production-shaped records and counts the duplicates, the empty required fields and the free-text columns holding three different formats. Cleansing is quoted as its own workstream you can defer.
What happens at three in the morning when a sync fails?
Nothing silent. Failed messages land in a dead-letter queue with the original payload attached, an alert fires on queue depth rather than on a single error, and your team can replay the batch from a console once the cause is fixed. The runbook names the three likeliest failures — expired token, rate limit, provider outage.
Often bought alongside
Tell us the requirement.
Thirty minutes with the engineers who would build it. You leave with a scope, a timeline and a fixed price — or an honest no, and the reason why.