Connecting a REST API took two days in one project. Clarifying who fixes the wrong record at night took three months. That is not an exaggeration to make a point, but the normal distribution in integration projects: the technology is up quickly, and then the project stalls. Not because something doesn't work, but because nobody has decided who answers for it when the other side behaves differently than it did yesterday.
When an SME talks about an integration, everyone pictures the same thing: two systems, an arrow between them, data flowing from left to right. The managing director hears "the two now talk to each other" and ticks the item off. The department hears "then I won't have to retype anything". And the IT lead hears something else, because he knows the arrow is the easy part. The arrow is built in two days. What isn't clarified in two days appears nowhere on the arrow.
Why the API is the harmless part
Modern systems make the pure connection almost boring. There is a documented REST API, a handful of endpoints, an authentication scheme, a data format. An experienced developer reads up on it in a morning and has transferred the first record by the next day. That very early success is the trap: it creates the feeling that the project is eighty per cent done, when the difficult eighty per cent hasn't even started yet.
Because an integration is not a one-off transport. It is a relationship between two systems that runs for years, and relationships don't fail on the first day. They fail on the day one side changes without asking the other. A field gets renamed. A mandatory field becomes optional. A date format switches from day-month to month-day, and from the fifteenth of the month onwards nobody notices any more, because until then both readings looked plausible.
The API is rarely the problem. Responsibility is.
The project that hung on one open question
In one of our projects, an inventory management system and a new shipping tool were to be coupled. Orders out, shipment status in, a stock-level reconciliation twice a day. The technical task was manageable: both sides had an API, the field mapping was sketched out in one afternoon, and the first real order ran through cleanly after two days. The status report showed green.
Then came the first record that didn't fit. An order with a delivery address that failed on character length in the shipping tool — a street name with an addition that had been allowed in the inventory system for years and, beyond a certain length, was simply truncated in the new system. The parcel would have gone to half an address. The integration reported the error correctly. Only: to nobody who was responsible.