Most of the work in an API integration is in its failure handling. While the client recovers from a dropped connection, expired access, or a response it has never seen, your application needs to know what it can still show, and when recovered data is safe to use again.

I build the client code for one workflow against a third-party API, in your language and environment. I use the source’s own SDK where it fits and write the behavior it leaves out.

Recovery depends on what the source can replay

Some APIs can replay events a client missed. Others offer only current state. I find out which before promising any historical coverage. When the source can’t replay, the client restores current state, records the interruption, and tells your application which period is uncertain.

The consuming application sets the requirements

The first conversation is about the part of your application that consumes the data. For a streaming source, that includes what the application shows during an interruption and what has to happen before it trusts the data again. From there we choose the endpoints or markets, the language and runtime, and where the client runs, and estimate the volume and latency it must handle.

You provide the API documentation, any credentials, and an application or test environment to integrate with, and tell me what data the client may keep.

A good first project is a read-only integration of one workflow. Long-term storage, reconstructing missed history, trading or order execution, and running the integration as an ongoing service are each projects of their own.

The client and its documentation

  • A client package as a versioned release, or a service with its deployment configuration, connected to your application’s data model.
  • Authentication, subscriptions or pagination, and handling for every error and interruption in scope.
  • Recovery suited to the source, whether that means resubscribing, refreshing state, or retrieving history the source can replay.
  • Working examples and automated checks for the failure cases.
  • Installation or deployment instructions and configuration guidance.
  • Metrics and logs that show failures, stale data, and recovery, with instructions for investigating a failed request or connection.

Each failure is rehearsed before handover

I run the integration in a clean environment against a test source whose events are known in advance, so what reaches your application can be checked against what was sent. Then I introduce the failures it has to survive, from interrupted pagination and expired access to an unfamiliar response or a consumer that falls behind.

For a WebSocket client, a reconnect passes only when subscriptions come back, affected state has been marked uncertain, and the application waits for the recovery conditions before using new data.

Source APIs keep changing after handover, and so do your dependencies. I can keep the integration current with both.

Which API are you integrating, and which part is hard to build or keep running? Send me the details on LinkedIn, along with your language or runtime.