What actually matters when you connect two systems
The hard part is never the API.
It's deciding which system owns each field, what happens on conflict, and who notices when it breaks. Get those three answers wrong and the cleanest API in the world will faithfully synchronize two systems into disagreeing with each other.
Every connection is one of five moves
Each has a right time. None is a failure mode — picking the wrong one for the situation is.
API
Vendor-supported, survives vendor upgrades, and bounded by exactly what the vendor chose to expose.
Right when the vendor's API covers the fields you actually need — which is the first thing to check, not the last.
Direct database
Full fidelity, no API ceiling. The tradeoff is that you're reading the vendor's schema, and the vendor never promised you they wouldn't change it.
Right when the API stops short of the data you need and access privileges are on the table.
SFTP
The oldest and least glamorous method, and among the most reliable. Batch by nature, auditable by nature.
Right when the counterparty speaks files — banks, EDI trading partners, legacy systems that predate the API era.
Screen scrape
Brittle by nature — it breaks when the interface changes, and the interface will change. We treat it as a bridge, not a foundation.
Right when no connection exists, the site and vendor permit it, and the data matters enough to accept the maintenance.
Be the system of record
Not an integration — the end of needing one. Co-Wright holds the data itself.
Right when no system fits the business, or you're paying a platform license for something that only holds data.
Why nightly beats real-time, most of the time
Real-time sync sounds like the premium option, so people buy it. For most mid-market reconciliation it's the wrong purchase. Reconciliation wants a stable snapshot, a full audit trail, and clean retry semantics when a source fails — all of which a nightly batch gives you for free, and all of which real-time sync makes harder.
Real-time also doubles your failure modes. A nightly job that fails is a morning problem with a clear fix window. A real-time pipe that fails silently is a disagreement between two systems that nobody notices until the numbers diverge in a meeting.
Who owns the mapping
"Which system owns the customer's address" looks like a technical question. It isn't. It's a question about how your departments work, and it has a different right answer in sales, in finance, and in the warehouse. The integration just makes the ambiguity visible — usually in a report, usually at a bad time.
This is why the mapping is part of the operational layer — the business within your business. Somebody has to own those decisions, keep them documented, and revisit them when the organization changes. That work is exactly what gets deprioritized when your engineers are, correctly, building your product. It's the phase-two work of the engagement.
Enhance & streamline →Connected systems are table stakes
Nobody's business improved because two systems exchanged data. It improved because a workflow that used to take six people and three documents now runs across both systems at once. The connection is plumbing; these are the reasons to build it:
Commissions
Commission truth lives in supplier files, the CRM, and the ledger at once — and someone owes people accurate statements on time.
Read the workflowRecruiting
Sourcing, pipeline, and retention live in separate tools, so nobody can say what a hire actually costs or which source produces the ones who stay.
Read the workflowBudgeting & planning
The plan is built outside the systems that hold the actuals, then re-keyed back in — months of work that is stale on arrival.
Read the workflowCompliance reporting
Obligations live in documents and deadlines nobody's system of record owns, and the cost of missing one is not proportional to the effort of tracking it.
Read the workflowBring the two systems that disagree
Thirty minutes on which fields fight, which method fits, and what the workflow on top would look like.