How to integrate two systems through an API

The initial request often sounds simple: “I need to connect system A to system B.” Further analysis usually reveals additional document formats, periods when one system is unavailable, duplicate records, and uncertainty about whether previous batches were processed.

The problem

Each system was built for its own process. The bridge has to translate data, respect limits, confirm receipt, and survive a peak. Without that, the integration becomes a spreadsheet in the middle or a cron that “sometimes works.”

How an integration that survives production works

• A clear contract for fields, authentication, and idempotency.
• Timeouts and retries with defined limits.
• Queues when the destination system is slower than the source.
• Sufficient logs to trace each identifier.
• Controlled reprocessing of failed data.

API or webhook?

An API is you asking or sending when you need to. A webhook is the other system notifying when something happened. Both fail in production if nobody handled timeout, signature, event order, and what to do with a duplicate notice. The choice depends on who owns the event, not on which word sounds more modern.

Why integrations fail in production

In testing, five messages. In production, a burst. The database locks on a query that was “fast.” HTTP times out. The sender retries and creates a duplicate. The receiver processes twice. Without a queue, idempotency, and observability, the symptom becomes “the API is unstable” — when the design is what never planned for load.

Practical experience

In tracking and continuous-data-collection projects, devices keep sending data regardless of database load. Payloads may differ from the documentation, and device models may behave differently than expected. Incorrect timeout settings can discard messages that should be retried, while an undersized queue can conceal growing delays. Ingestion, persistence, and querying must be monitored and scaled as separate components.

Common mistakes

• Integrating through the database directly because “it is faster.”
• Assuming the partner documented the full protocol.
• Ignoring timezone, encoding, and an optional field that one day arrives filled.
• Having no owner for the integration after go-live.

When to add a new API to an existing system

When the legacy system needs to talk to a channel, AI, mobile, or another ERP without rewriting the core all at once. The API is the seam. The old system continues; the new world does not need to enter through the back door of the database.