
Ask HN: How to plan for breakage of critical upstream APIs? - austinjp
Many PaaS&#x2F;SaaS startups rely on upstream services that are accessed via APIs. Unfortunately, the provider may break the API, resulting in a temporary or permanent loss of some or all of the startup&#x27;s revenue. Example: your business provides photo filters for social media and Instagram changes&#x2F;breaks&#x2F;revokes your API access. That&#x27;s significant and may kill your business [1].<p>If an API-dependent startup asked me for investment I&#x27;d ask &quot;What happens if these critical APIs break?&quot;<p>I&#x27;d expect to hear something like this:<p>1. We’ve discussed API use with the providers and we have good contacts at each. We have high confidence that API access will not be revoked, and we can expect a prompt response if breakage occurs. (Ideally there would also be a contract featuring API availability guarantees.)<p>2. We operate within each provider&#x27;s Terms of Service and our business model does not conflict with the providers&#x27; business models.<p>3. Customers could continue to use our PaaS by manually uploading their data and fetching the output from our service.<p>4. We&#x27;ve reverse-engineered official consumer client software and could impersonate consumers, thereby continuing to access official APIs. (Obviously plenty of questions here about good-faith, legality, ToS, etc.) For example see [2].<p>Additionally I&#x27;d like to hear:<p>5. We&#x27;ve analysed the likelihood of each provider obsoleting our product by offering our service direct to their customers.<p>Each of these has pros &amp; cons and I don’t suggest any is ideal or desirable. However I’d expect to hear a detailed response on how to handle revocation&#x2F;breakage of business-critical upstream APIs.<p>How would you answer this question?<p>What other responses would you want to hear?<p>[1] https:&#x2F;&#x2F;www.macrumors.com&#x2F;2016&#x2F;06&#x2F;02&#x2F;instagram-third-party-apps-websites-dead&#x2F;<p>[2] https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14605342
======
sharemywin
I would build/buy some kind of service broker that takes queries and passes
them to the service.

~~~
austinjp
If I understand correctly, you're suggesting a startup in this position would
buy access via a broker who might offer a single API which can be used to
access all upstream business-critical APIs..?

True... although it feels a little like "kicking the can down the road". Now
you have two dependencies: the broker themselves _and_ the upstream API
providers.

As an investor I'd still ask "What would you do if the broker revokes your
API?" \-- and now I'd also want to do due-diligence on the broker by asking
them all the above questions too.

Additionally the broker may be prohibitively expensive.

See this recent discussion about teller.io which in part prompted this
question:

[https://news.ycombinator.com/item?id=14605342](https://news.ycombinator.com/item?id=14605342)

~~~
sharemywin
personally I would build a service broker. it mitigates the technical risk
some. Consolidates the code dependencies to the service broker. You will need
to build a translation if you switch services.

