How to Integrate APIs in Your Business

An API integration exists so that a piece of data stops being typed twice. The typical small-business case is concrete: an order arrives in the shop and someone retypes it into the invoicing software, and again into the stock sheet. What is lost there is not only time, it is discrepancies where nobody knows which figure is right.

Before integrating it is worth measuring the manual process: how many times a day it happens, how long it takes and how often it fails. If it is ten minutes a week, automating it costs more than doing it. If it is two hours a day with errors, the integration pays for itself in weeks.

• Shop orders into the invoicing system
• Warehouse stock into the website catalogue
• Contact forms into the sales CRM
• Gateway payments into accounting
• Customer data into the email tool

The decision that saves the most trouble later is which system is the source of truth for each field. If a product price can be edited in the shop and in the ERP, sooner or later they diverge and the integration becomes an overwrite war. One field, one place it is edited, and everything else receives it.

The second decision is direction: whether synchronisation goes one way or both. Bidirectional is far more expensive to build and to debug, and most real cases are solved one-way once the source of truth has been decided properly.

• Which system owns each field, written down and agreed
• One-way synchronisation whenever possible
• What to do when both sides change at once
• How up to date the data actually needs to be
• What happens to historical records already out of sync

There are two ways of learning that something changed in the other system. Asking periodically is simple and works anywhere, but it burns calls and arrives late. Webhooks notify immediately and are far more efficient, but they require a publicly reachable URL and verifying that the caller is who it claims to be.

A practical detail discovered late: webhooks are delivered more than once. The network fails, the sender retries, and the same notification arrives two or three times. If the receiver is not prepared, an order is duplicated and a payment is booked twice.

• Periodic polling: simple, no public URL, with delay
• Webhooks: immediate and efficient, require a public endpoint
• Always verify the webhook signature before processing
• Assume it will arrive twice and store the event identifier
• Answer fast and process afterwards, on a queue

Every integration fails at some point: the other system goes down, changes a field or returns a rate-limit error. The difference between a good integration and a fragile one is not that it never fails, it is what it does when it does. Retry with growing waits and a cap, and park whatever could not be processed in a separate queue.

The piece that prevents disasters is idempotency: processing the same message twice produces the same result as processing it once. It is achieved by storing the identifier of each event already handled and discarding repeats before touching anything.

• Retries with growing waits and a maximum count
• A stored event identifier to discard repeats
• A dead-letter queue that somebody genuinely reviews
• An alert when that queue grows, not once it is too late
• A log of what was sent and received, so it can be audited

An API key is a password with every permission the account has, and it leaks surprisingly easily: in a repository, in browser JavaScript, or in a screenshot sent over chat. The operational rule is that keys live on the server only, in environment variables, and are never sent to the frontend.

It is also worth requesting the minimum permission the integration needs and rotating keys periodically. Where the API allows it, separate credentials per environment and per integration: that way a leak is contained and can be revoked without stopping everything else.

• Keys on the server only, never in browser code
• Environment variables, never in the repository
• The minimum permission the integration actually needs
• Separate credentials for testing and production
• Periodic rotation and immediate revocation on suspicion

An integration is not delivered and forgotten: it depends on someone else's system that changes without telling you. APIs get versioned, old versions get retired and fields get modified. It is worth subscribing to the provider's change feed and knowing which version you use and how long it is supported.

What really makes the difference is monitoring. An integration broken silently is worse than a visible outage: orders keep arriving, nobody sees them reach the other side, and the problem surfaces when the mismatch is already weeks old.

• Subscribe to the provider's changelog
• Know which version you use and how long it is supported
• Alert when events stop arriving, not only when they fail
• A periodic reconciliation between both systems, even weekly
• Document which field goes where for whoever comes next