APIs have taken a very big place within every developer's life, certainly because they all provide key services over simple HTTP requests.

Today, you can send SMS to anywhere in the whole world using Twilio. Stripe gives you the opportunity to take payment without friction in 34 countries. And they are countless other no-brainers that add value to our business every day.

Do you know how many APIs does your business rely on?

If your project is quite young, I bet that you are already around 3 (payment, emails, and analytics). If it’s a few months old, that’s probably x2 time more already! Think about CRM, dev-tools, etc. And as long as your project is growing, you gonna use more and more of them.

Corentin Brossault

@frenchcooc

How many APIs does your SaaS rely on?

14:07 PM - 09 Jan 2020

The thing is APIs fail. In 2019 alone, @stripestatus reported ~70 issues.

Stripe Status

@stripestatus

On 2019-07-10 UTC, the Stripe API had two periods of severely degraded availability. Our root cause analysis: stripe.com/rcas/2019-07-10

17:11 PM - 12 Jul 2019

I’m taking Stripe as an example as they are probably the best to publicly report every single issue. Not all of them impacted the API. Some issues were one minute long; some a few hours long.

It’s something that, as developers, we are all aware of. But do you take any action to avoid that?

For the majority of us, if Stripe is down, it’s going to be only for a few minutes, no? Then, only a subset of the user base is going to be impacted. And it probably doesn’t worth the effort to take any action to counter it 🤔

Well:

• Most APIs aren't as trustworthy as Stripe API (& even Stripe fails)
• From a user perspective, it's not the API that fails, but your app.
• It can lead to very long debug sessions to "solve" what was just a network issue.

How to monitor these APIs?

To make sure that third-party APIs you rely on are always live, status pages are a good starting point. But they are manually updated by the API provider. Thus your product might be already collapsing even before the status page is updated.

That's why you should monitor API calls right into your app.

Logging outcoming HTTP requests is a step further, but make sure to (i) configure notifications in case of failure and (ii) log the full HTTP request (with the data sent) and the full response (with payload). They are critical information to help you understand what’s going on.

Building robust logging for your app takes times and a monitoring solution is probably best. Grafana is an open-source and well-known solution that you can trick to watch outbound APIs calls.

But I’d highly recommend a dedicated solution, like Bearer.sh (disclaimer: I’m a developer advocate at Bearer). Using a Node.js or Ruby package, it helps you add a monitoring solution to your app with a few commands:

What you should monitor?

Whatever the tool you pick, make sure that it helps you:

• Understand your API consumption: how many API calls do you make? On which API? At which rate?
• Debug any issues quickly. It’s best to have a full overview of the request, with full headers and body (like you would have with the Network tab of your browser dev-tool).
• Compare APIs: which one is faster to respond to? Which one has a lower error rate? It might help you prefer one service to the other and it can lead to business decisions. Like should I use Sendgrid API over Mailchimp API to send emails?
• Stay informed with notifications: for example, you can receive a Slack notification anytime that a critical API fails? But you also receive weekly emails to stay informed of the overall status.

Monitoring third-party APIs is key (sic) to know what's happening behind the scene. It takes time to build it yourself, but it clearly worth the effort.

If you want to know more about monitoring APIs that your app consumes, let's chat below 👇