Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How to plan for breakage of critical upstream APIs?
1 point by austinjp on June 23, 2017 | hide | past | favorite | 5 comments
Many PaaS/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's revenue. Example: your business provides photo filters for social media and Instagram changes/breaks/revokes your API access. That's significant and may kill your business [1].

If an API-dependent startup asked me for investment I'd ask "What happens if these critical APIs break?"

I'd expect to hear something like this:

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.)

2. We operate within each provider's Terms of Service and our business model does not conflict with the providers' business models.

3. Customers could continue to use our PaaS by manually uploading their data and fetching the output from our service.

4. We'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].

Additionally I'd like to hear:

5. We've analysed the likelihood of each provider obsoleting our product by offering our service direct to their customers.

Each of these has pros & 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/breakage of business-critical upstream APIs.

How would you answer this question?

What other responses would you want to hear?

[1] https://www.macrumors.com/2016/06/02/instagram-third-party-apps-websites-dead/

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




I would build/buy some kind of service broker that takes queries and passes them to the service.


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


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.


also, if your chasing a single point of failure then you probably need to diversify if possible. look at the chip maker that just collapsed because apple stop using them. or many businesses that got killed buy walmart's bad contract terms.


might also have a backup container on competing platforms(AWS/Azure) so you have most of the deployment worked out should things goes south with a provider.

Although those types of risks probably aren't worth chasing as early stages.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: