Most integration requests arrive the same way. Two products both hold customer information, and someone is retyping it. The fix sounds like it should take an afternoon. It usually does not, and the reasons are worth understanding before you scope the work.
Deciding which system is right
Before any code is written, someone has to decide which system is authoritative for each piece of information. If the CRM and the accounting package both hold a billing address and they disagree, the integration needs a rule for which one wins.
This is a business decision, not a technical one, and skipping it is the most common reason integrations create more confusion than they remove.
Failure handling is most of the work
The happy path is usually straightforward. The real work is what happens when a vendor API is down, a record is rejected for a validation error, or the same message arrives twice.
- Retries with sensible limits so a temporary outage recovers on its own
- A queue so nothing is lost while the other side is unavailable
- Duplicate protection so a repeated message does not create a second record
- Logging that makes a failure visible instead of silent
- Alerts to a person when something needs a human decision
When there is no API
Plenty of important business software has no modern interface. That does not end the conversation. Scheduled file exchange, vendor import formats, and direct database access are all workable depending on the system and the licensing.
What matters is confirming which of these is actually available before the work is quoted, rather than discovering it halfway through.
What a finished integration should include
A completed integration is more than working code. It should come with a written map of what moves where, in which direction, and how often. It should have logging you can read without a developer. And it should be observable enough that you learn about a problem from an alert rather than from a customer.
