How to manage external API dependency risk before building your product

Before building a product around an external API, distinguish a temporary outage from a policy change that removes your ability to operate the product at all. For each critical dependency, define what customers can still do, which information you control, and who makes decisions if the provider stops serving you. Put those answers into the product specification and acceptance tests before development begins.

What does Twitterrific teach us about platform dependency?

On January 19, 2023, Iconfactory announced that it was discontinuing Twitterrific. According to its announcement, an unannounced and undocumented Twitter policy change caused the closure. The team asked iOS subscribers to consider not requesting refunds, explaining how a large number of refunds would hurt the small company. This affected the business model, beyond a technical interruption that another software release could resolve.

The story does not establish that building on external platforms is always a mistake. It illustrates that access to a platform belongs among the business assumptions behind a product. Our interpretation is that founders should examine that assumption before investing in screens and features: if access disappeared tomorrow, would customers still have something worth paying for? A negative answer does not automatically invalidate the idea, but it changes the risk worth taking.

Which dependencies should you investigate before development?

Start with the main action your customer performs, then identify the services needed to complete it. A product that organizes customer inquiries might depend on a messaging provider, an identity service and an AI model. Their importance differs. An automated recommendation might be able to wait, while losing access to the original messages could stop the entire workflow. A useful dependency map describes what the user loses, rather than merely listing vendors.

For each provider, record who owns the account, who can export information, which usage limits apply, and what depends on a particular commercial plan. Read the service terms relevant to your product and check whether your intended activity is permitted. Being technically able to retrieve data through an API does not establish permission to use it for every purpose. Resolve significant uncertainty with the provider before committing that capability to a customer.

How should the product behave during an outage?

Set a reasonable waiting period for each action and specify what happens when it expires. An indefinitely loading screen leaves users without information or a useful choice. Sometimes you can show saved information with its last update time. Sometimes you can offer partial functionality. For other actions, you need to stop and explain that the operation has not completed. The right choice depends on the consequences of stale information or duplicate execution.

For example, retrying a request after a connection drops can create a duplicate if the provider already completed the original operation. A retry design therefore needs a way to identify the same operation and inspect its outcome, using the provider's supported capabilities. A policy suitable for fetching an article is not automatically appropriate for collecting a payment. Have the team document that difference explicitly and cover it in acceptance tests.

What happens on the Julius website when its content source is unavailable?

In the Julius website code, the content reader tries to fetch articles, authors and topic clusters from Supabase. If the reads fail or required tables are empty, it returns a local collection of content included with the website code. The read layer also sets a deadline for read requests. This is an existing example from our own site of separating basic content availability from the availability of an external service.

The compromise is clear: the local collection does not necessarily contain the latest publications. That makes it useful for preserving basic website content, rather than promising that every item is always current. It would not justify presenting an old account balance as a current one. When designing fallback behavior, document what it does not preserve as well as what it does, so the business promise remains accurate.

When is it worth preparing to switch providers?

Before integrating two providers, establish whether switching is actually possible. If a provider controls a unique user network or permission that only it can grant, replacing a library will not recreate that value. Where several vendors offer a similar capability, separating business logic from the provider connection can reduce migration work. Even then, you need to examine differences in data formats, behavior and operating costs.

Early preparation can be modest and practical: retain a permitted copy of essential information, document an export format, and record who controls keys and accounts. You do not need to implement every possible failure scenario in advance. Compare preparation costs with the damage from a day without the service, and ensure that infrastructure work does not displace the product's central validation question. This belongs within MVP scope definition, rather than necessarily becoming a separate infrastructure project.

What should you ask your software team to demonstrate before launch?

Ask for a demonstration of a core action when the provider returns an error, when the response is delayed, and when authorization is invalid. In each scenario, inspect what the user sees, whether duplicate information is created, and who on the team knows that something failed. An explanation that the system can handle errors is insufficient: the demonstration should show the actual screen and recovery path. Agree beforehand which failures block launch and which can wait.

Finally, decide who can pause an operation, switch to a manual process or notify customers. Connect that responsibility list to the project handover plan, so knowledge does not remain with the developer who built the integration. Bringing a short dependency map and one failure scenario into a specification discussion makes it easier to decide development scope, cost and the customer promise. It is a practical starting point for discussing your product with the Julius team.