The traditional definition of API monitoring has been around for years from companies like SmartBear, APIMetrics, and Runscope and useful to check API correctness and performance. An API monitoring tool initiates API calls against your chosen endpoints and then records the response received. Additional checks can be added such as create a slack alert on a 500 error or timeout. The test can be started either on a trigger (such as when a new version is deployed by your CI/CD pipeline) or on a recurring schedule (such as every 1 minute). API monitoring tests can be simple such as simple health and uptime checks or can be very elaborate running through a long sequence of API calls and checking against specific status codes, body fields, and more.
While API monitoring enables you to check for uptime and take action if your API has time outs or responds with 500 errors, it also limited due to it being a blackbox form of monitoring with assertion checks created ahead of time. The test or probe is already known ahead of time which means API monitoring is unable to answer arbitrary questions on how your API is behaving. Instead, API monitoring can only check on the traffic that it generates, not actual customer API traffic. As more APIs are exposed to the internet, there are new requirements to explore and find unknown unknowns for preventing API threats, troubleshooting customer issues, and understanding API usage. These requirements led to the emergence of API Observability.
Unlike blackbox testing and monitoring, API observability is a form of whitebox monitoring that requires an agent or SDK to passively log API traffic to an observability service. This data collection can be done within the application or add a different point such as with an API gateway like Kong or NGINX.
Uses cases for API Observability
Monitor customer experience
API observability can track every interaction a user or customer has with your API which enables you to profile different end-to-end flows and understand where hot spots may exist. Most teams providing APIs don’t have full control over how their consumers will exercise the API. Those consumers could be from another department or product with a large organization or a different company all together. As developers, we like to assume a customer will use our products in a specific way but API integration work can be messy or buggy. For example, you may have API consumers who ignore your recommendations on pagination and filtering causing an excessive amount of data to be polled. The goal of API observability is to proactively discover these unknown unknowns and remedy them whether it’s something wrong with your own code or the API consumer’s code.
Troubleshoot API issues
Because an API observability tool logs everything happening over the API, you’re able to explore unknown unknowns such as an issue a customer may be having that you’ve never seen before. You don’t need to create a test ahead of time to observe what happened. There are a variety of API issues that pop up, some are easier to investigate such as missing an API key or HTTP header, but others can be far more complex that requires tracking the history of API calls and their timing.
Detect and protect from API threats
A well designed API Observability platform not only tracks what is happening over the API, but also who is making those API requests which enables sophisticated User Behavior Analytics (UBA) and User and Entity Behavior Analytics (UEBA). By tracking complex user flows, you can identify suspicious users who may be scraping your API or accessing unauthorized data.
Unlike a web application which can incorporate technology like Capctha and browser fingerprinting, an API exposes raw access to your data. Some APIs may even have customers accessing programmatically which makes it extremely hard to distinguish real API calls from malicious ones. This makes traditional rule-based Web Application Firewalls (WAF) like ModSecurity useless for APIs. Instead, modern API observability solutions that take a user-centric approach can detect unknown unknowns using advanced anomaly detection.
Understand customer API usage
Organizations build APIs to create something of value for the customers or users of the API, not just for the sake of building things. Like API security, this requires a mechanism to attribute API calls to individual customers and their revenue and is another use case for User Behavior Analytics (UBA) for APIs. Common teams looking for API analytics include the product org, but also sales and growth teams to track pilot usage, trials, and expansion opportunities. It was only in 2015 that Twilio was valued at $500 million. Now it’s a $30 billion company and a staggering 83% of all HTTP traffic comes from API calls according to Akamai. APIs are no longer just a “backend technology,” but a key business driver.
Yet, the API calls only tell half the story (engagement), a good API observability tool also provides the ability to store customer demographics and revenue (for monetization and segmentation) along with tracking what happens outside of the API such as sign ups and plan purchases.
Deep API Observability with Automatic InstrumentationLearn More
Pillars of API Observability
API metrics enable you to monitor both engineering and business KPIs such as performance and customer usage. Some metrics tracking tools can only monitor single-value metrics like requests per minute. However, a key theme for observability is the ability to answer any question around your API and services without planning ahead for which metrics need to be monitored. This is where high-cardinality, high-dimension metrics and data stores can become handy to explore and answer unknown unknowns with the ability to slice and dice instantly.
Like API metrics, an API observability platform also has the ability to inspect API calls in real-time for debugging and auditing. API logs show you the exact calls in an instant in time. Because an API is by definition structured unlike traditional logging, API logs can also be used for generating aggregations and metrics while maintaining context. However, API calls can have a large number of HTTP headers, body keys, and attributes. This means your API observability tool should be capable of filtering and aggregating by them without relying on a full scan of your data store (which can take forever).
GDPR and CCPA require new procedures for things like API logs which are used across the company from security teams to business teams. You can no longer simply dump API logs into a log management solution. Instead, API businesses need a way to export and delete (or anonymize) all the associated logs and events specific to a single customer. This means API logs have to be tied to some permanent user identifier (and not just API keys which are rotated).
A third pillar of API observability is API analytics. Unlike API metrics and logs which focus on answering engineering specific questions, API analytics is focused on answering product and business related questions. API analytics in a nutshell is the convergence of API metrics with data on who the customers are and how they are using your APIs. Many times API analytics tools can pull data from other systems like your CRM or marketing automation tools so you’re able to map out the customer journey. API analytics can include funnel metrics like how many people activate and use your API to understand which endpoints generate the most revenue or growth.
Being transactional in nature, APIs contain timing information on when the request was initiated, how long it took the service to respond among other times. Different timing can create race conditions and bugs that are hard to reproduce. API traces make it easy to understand how long different services take to respond and where timing errors can occur. Traces enable you to further explore which logs to look at for a particular session or related set of API calls.
Anyone looking to ship APIs with speed and confidence should be looking for an API observability system. APIs provide the window to the rest of your companies infrastructure and enable entirely new digital experiences, but traditional monitoring can only answer already known questions like “Is my API down”, but cannot answer arbitrary questions required for data-driven engineering and business teams, nor report on actual customer API usage needed for security and product analytics.