API Integrations

Payment systems are the most recurring category, both on e-commerce and on other kinds of application that need to take money. Next come CRMs and ERPs, which is where integration stops being a technical problem and becomes a question of aligning data across different departments.

The third category is newsletter and mail sending platforms, where the delicate part is rarely the API itself: it is consent handling, deliverability, and the gap between the list a company believes it has and the one it actually has.

The most demanding integration I have worked on is with Meta for the WhatsApp Business APIs, built inside the Messagent platform, currently live for the Basko and Despar Nord Ovest retail brands.

The complexity is not in any single call, but in the fact that the channel imposes its own rules on what can be sent, when and in what form, with time windows and message templates that must be approved in advance. On top of that sits its conversational nature: the system does not answer an isolated request, it has to keep conversation state per user, recognise them, know which brand and which store they belong to, and react accordingly.

In Messagent this coexists with multi-tenancy, where each brand has its own numbers, credentials and keywords, and with scheduled message delivery that must remain guaranteed even across service restarts. These are exactly the requirements that separate a demo integration from one that holds up in production.

The part that needs the most care is not the path where everything works, but all the rest: what happens when the remote service responds slowly, when it returns a recoverable error, when it does not respond at all, and how you avoid duplicating an operation that already succeeded after a retry.

That is why a delivered integration always includes error handling, retry logic, call monitoring and interface documentation in OpenAPI format, so whoever comes next does not have to infer it from the code.