API Integration: How Modern Applications Connect Systems

Modern software rarely operates alone. An application typically talks to payment services, authentication providers, databases, communication platforms, analytics systems and other applications. Interfaces between systems are how that happens.

What is an API?

An API is an agreement between two systems about how to communicate: what can be requested, what arguments are accepted, and what a response will look like.

The value is the agreement, not the transport. Either side can change internally as long as the agreement holds — and when the agreement changes without warning, every consumer breaks at once.

How does a request work?

A typical interaction has two halves.

A request carries an endpoint, a method, parameters, headers and often a body. A response carries a status, headers, data and, when things go wrong, an error.

The common methods express intent: GET retrieves, POST creates or submits, PUT and PATCH update, DELETE removes. Exact semantics depend on the design — PUT replacing a whole record and PATCH amending part of one is a convention rather than a law, and reading the documentation beats assuming.

The property worth designing for is idempotency: whether sending the same request twice is harmless. Networks retry. A payment endpoint that charges twice because a response was lost is a defect in the interface, not in the network.

How is access controlled?

Interfaces commonly require authentication: keys, bearer tokens, delegated authorisation flows, or session-based schemes.

The rule that matters more than the mechanism: a credential intended to stay secret must never reach client-side code. Anything in a browser bundle or a mobile binary is readable. Secrets belong on a server you control, which is one of the main reasons applications route third-party calls through their own backend rather than calling out directly.

What goes wrong?

A reliable integration expects failure, because the other system is not under your control. Plan for invalid input, authentication failures, rate limits, timeouts, unavailable services and responses that do not match the shape you expected.

Each deserves a deliberate decision. Retry, with backoff, and only for errors that might succeed on a second attempt — retrying a rejected payload simply fails more slowly. Fail loudly enough that someone finds out from monitoring rather than from a customer.

Validate what comes back. A response is external data, and trusting its shape because it was correct yesterday is how an integration breaks silently.

What does the architecture look like?

In a typical system the user talks to the application, the application talks to its own backend, and the backend talks to everything else — payment, messaging, customer records, AI services, analytics.

The backend acts as the controlled integration layer. That placement is deliberate: it keeps credentials server-side, gives one place to handle retries and failures, lets you swap a provider without touching the client, and means a third party's outage degrades one feature instead of the page.

1. 01UserTalks to the application.
2. 02ApplicationTalks to its own backend.
3. 03BackendHolds credentials, retries and failures.
4. 04Services
   • Payment
   • Messaging
   • Customer records
   • AI services
   • Analytics

What should an engineer consider?

• Versioning — how a consumer survives the interface changing.
• Rate limits — both the ones you are subject to and the ones you impose.
• Timeouts — a call with no timeout is an outage waiting for a slow dependency.
• Idempotency for anything that changes state.
• Observability — which calls were made, how long they took, what failed.
• Data handling — what you are sending to a third party and whether you are permitted to.
• Graceful degradation — what the user sees when a dependency is down.

The practical conclusion

Good integration is not connecting endpoints. It is designing a reliable boundary between systems you control and systems you do not.

---

Related reading: websites versus web applications, and database design.