3rd Party API Integration Pattern

Overview

Most applications at the enterprise, mid-size, or even startup levels, would have one or more 3rd party APIs they integrate with. It may start off with just one component talking to the external API, but can very quickly grow into multiple systems talking to that 3rd party API. It’s not a good practice to have direct integrations for all those different systems. Instead, a good pattern is to have a 3rd Party API Integration Service, deployed as a company wide API, where this API acts as the gateway between the 3rd party system and systems within your application / enterprise.

Integration Service Pattern

The benefits of this pattern are mainly that the integration service insulates the rest of the ecosystem from the external API. This helps avoid negative coupling spread throughout the system as well as redundant codebases that could all very quickly go out of sync. All interactions are done in one system and one codebase, which makes it significantly simpler to maintain. Most such integration services often serve multiple functions.

• Authorization – All of the auth code to the 3rd party API is managed in this one service.
• Caching – If the 3rd party API is expensive or not as performant as you’d like it to be, you can add a fast caching layer here (and use something like Redis for recent repeat calls).
• Schema Transform – You can transform the schema to a more company compliant standard.
• Data Filtering – This would be a simple place to filter out certain results or certain fields within results.
• Model Enrichment – You can enrich the 3d party response by adding internal system identifiers, which will make it far easier for downstream callers to resolve entities.
• Local DB persistence – All fetched data can be persisted locally, meaning that in a future scenario where the 3rd party API may not be available to integrate with, you still have the original data.

And the fact that you have this integration service means that you can switch 3rd party services without the internal systems having to make any changes. A new version of the integration service will abstract away the new external API and convert the data to the same format expected by the downstream callers.

References

• Original version published on Nish's blog