APIs are everywhere within your organization. Many may be internal, but we’re willing to bet there are many third-party web services and APIs that your business depends on too. Keeping track of them all, and ensuring that your team chooses the best APIs for their needs can be a challenge. In some cases, your organization may be using an API they don’t even know about. The solution to this “web of APIs” is to apply the concept of API governance to your API dependencies.

Webhooks run a large portion of the "magic" that happens between applications. They are sometimes called reverse APIs, callbacks, and even notifications. Many services, such as SendGrid, Stripe, Slack, and GitHub use events to send webhooks as part of their API. This allows your application to listen for events and perform actions when they happen. In a previous article, we looked at how to consume webhooks with Node.js and Express.

APIs are stable, until they aren’t. We talk about that often at Bearer. If you control the APIs, it gets easier, but with third-party APIs and integrations it can be more difficult to predict when an outage or incident is about to happen.

Machine learning (ML) used to be a tool limited to specialized developers and dedicated teams. Now, thanks to many web service providers and approachable tooling, your applications can use pre-build learning models and machine learning techniques the same way you would use any web service API. This is a quick way to test out and benefit from machine learning without having to invest in artificial intelligence, building your own learning models, or shaping your application around ML.

This guide explains how to get started with any Google API, such as Google Maps, Google Calendar, Youtube, or Google Sheets. Google's APIs can allow your application to integrate with Google services on the web or in a native application. There are three types of credentials for Google APIs.

The concept of instrumentation often refers to tracing where events happen in an application. Many application performance monitoring (APM) tools use it to provide metrics on the inner workings of your application. But sometimes, all you really need are details about API calls.

Note: This is Bearer's monthly newsletter. Subscribe below to get it in your inbox. I hope you are doing well with this never-seen-before-worldwide-lockdown. The whole Bearer team is locked down as well, but still improving your beloved product! We have a lot of updates and awesome new features for you to explore today. Here is a short overview to get you started!

Modern applications aren’t built in silos. They rely on the features of other applications. This reliance can come in the form of open-source libraries, access to a wealth of data, or complex features distilled down into a consumable API. Incorporating third-party dependencies into your own project can be challenging. It comes with the benefits of faster development, and the downside of reliance. There is a relationship that happens when using a dependency.

In Ruby, like in most languages, an exception is a way to convey that something went wrong. While some languages only use exceptions for truly exceptional circumstances, like run-time errors, Ruby uses exceptions for a wide variety of errors and unexpected results.

Whether you're making API calls from Node.js or in the browser, connection failures are going to happen eventually. Some request errors are valid. Maybe the endpoint was wrong or the client sent the wrong data. Other times you can be sure that the error is the result of a problem with the connection to the server or one of the many hops in-between. While API and web service monitoring can inform you about the problem, a more active solution can take care of it for you.