Systems that pass on
the right data.

I start with data mapping: sources, destinations, ownership of important fields and the rules that define a complete, valid record.

What an API integration actually solves

Teams often use several tools that work well on their own, while their data remains separated. An order is entered in one system, its status is copied into another and the report is assembled from a spreadsheet.

An integration can transfer new records, synchronise status, prepare inputs or trigger the next task. The goal is not to connect everything to everything. It is to remove a specific manual handoff while keeping control over the result.

Webhook, polling or batch?

A webhook fits when the source can notify a change immediately and the destination can accept it safely. Polling works when the system must be checked regularly and provides no event mechanism. Batch processing is often better for reports, larger volumes or workflows where a short delay is acceptable.

The choice depends on API limits, history, volume and what should happen when the destination is unavailable. A faster transfer is not better if it cannot safely repeat an unfinished operation.

Data mapping matters more than endpoint count

The same customer may have a different identifier in each system. “Sent” may not mean the same as “closed”. A date may use another time zone. Those differences decide whether an integration reduces work or only moves errors elsewhere.

• define the source of truth for each important field,
• describe conversions of names, formats and statuses,
• validate required fields and incomplete records,
• define what happens when two systems disagree,
• keep the transfer traceable without storing unnecessary sensitive data.

What must survive an outage

An external service can return an error, respond late or confirm a request after the connection has already been interrupted. I separate sending from evaluating the result, store the job state and repeat only operations that are safe to repeat.

The design may include a queue, rate limits, an idempotency key, alerts for failed transfers and a view that shows where the integration stopped. The point is to repair a problem without searching manually through several systems.

How I hand over an integration

1. System map: sources, destinations, ownership and data relationships.
2. Interface review: access, limits, test environment and change policy.
3. First direction: one concrete transfer with a clear result.
4. Operations: logs, retries, alerts, documentation and a manual recovery path.

What improves as a result

A good integration is not just another technical layer. It reduces manual copying, makes data ownership clearer and shortens the time needed to find a failure. The team can see what is current, what is waiting and who can resolve the issue.

If the process itself is unclear or its rules change constantly, I recommend fixing that first. Integrating uncertainty only spreads unclear data faster.