An API (application programming interface) is a set of rules that lets one piece of software talk to another. When you check the weather on your phone, pay for a ride, or log in with your Google account, an API is handling the data exchange behind the screen.
This guide walks through real api examples with actual request/response snippets, explains the most common API types, and covers the part most articles skip: what happens when APIs break inside a mobile app, and what you can do about it.
What is an API?
An API is a contract between two systems. One system (the client) sends a request. The other system (the server) sends back a response. The API defines what requests are allowed, what format the data should be in, and what you'll get back.
Think of it this way. Your mobile app needs to show a user's order history. The app doesn't store that data itself. It sends a request to a backend server: "Give me the orders for user #4521." The server looks up the data and sends back a structured response (usually JSON). The app then renders it on screen.
That request-response cycle is what every API does. The details change (REST vs GraphQL, JSON vs XML, auth tokens vs API keys), but the pattern is the same.
A real API example in 30 seconds
Here's an actual API call to the OpenWeatherMap API. You send this from a terminal, a script, or a tool like Postman:
The server responds with something like:
That's it. You asked for weather data. The API returned it as structured JSON. Your app can now pull main.temp and display "14.2 C" to the user.
Every API follows this same loop: make a request to a URL (called an endpoint), include any required parameters or authentication, and parse the response.
Common api examples by type
APIs come in a few flavors. The differences are in how you structure requests and what you get back.
REST APIs are the most common. They use standard HTTP methods (GET, POST, PUT, DELETE) and return JSON. Most public APIs are REST.
Stripe's payment API is a typical REST example. To create a charge, you send a POST request:
Google Maps is another. When a ride-sharing app shows you a route, it's calling the Maps Directions API with an origin and destination, and the API returns turn-by-turn coordinates.
GraphQL APIs let the client specify exactly which fields it wants. Instead of hitting multiple REST endpoints, you send a single query.
GitHub's GraphQL API is a good example. To get a user's name and their last 5 repositories:
The server returns only the fields you asked for. No extra data, no wasted bandwidth. This is why GraphQL is popular in mobile apps where network efficiency matters.
Webhook APIs work in reverse. Instead of your app asking the server for data, the server pushes data to your app when something happens.
Stripe uses webhooks to notify your backend when a payment succeeds or fails. You register a URL, and Stripe sends a POST request to it whenever an event fires:
Your backend receives this, updates the order status, and the user sees "Payment confirmed" in the app. No polling required.
API examples you use every day without knowing it
Most people interact with dozens of APIs daily. Here are a few that are running every time you open your phone.
When you tap "Sign in with Google" on an app, that's the OAuth 2.0 API. The app redirects you to Google's login page, Google authenticates you, and then sends a token back to the app. The app never sees your Google password. It just gets a token that confirms you are who you say you are.
When you order food on a delivery app, a stack of APIs fires in sequence. The app calls a restaurant menu API to load items, a pricing API to calculate totals, a payment API (usually Stripe or Razorpay) to charge your card, a geolocation API to track the driver, and a push notification API (Firebase Cloud Messaging or APNs) to tell you when the food arrives. Each of those is a separate API call.
When Uber shows you a car moving on a map, that's the Google Maps SDK calling the Directions API and the Geocoding API in real time, while Uber's own backend API pushes the driver's coordinates to your phone every few seconds via a WebSocket connection.
These aren't abstract concepts. They're running in production, on real devices, right now. And when any one of them breaks, the user experience falls apart.
What happens when APIs fail inside your mobile app
This is the part most "api examples" articles don't cover. APIs fail all the time. Servers go down. Responses come back slow. Payloads change without warning. Rate limits kick in. And when that happens inside a mobile app, the user doesn't see a 500 status code. They see a blank screen, a frozen button, or a payment that goes through twice.
Here are the common failure modes:
A timeout on the payment API means the user taps "Pay" and nothing happens for 10 seconds. They tap again. Now you have a double charge.
A changed response format from the backend (say, a field name changes from order_id to orderId) and the app's JSON parser returns null. The order confirmation screen shows nothing.
A 403 from an expired auth token and the user gets silently logged out mid-session. They lose their cart.
A slow geocoding response and the map shows the wrong pickup location for 3 seconds before correcting itself. The user has already confirmed the wrong address.
The tricky part is that these failures often don't show up when you test the API in isolation. You can hit the endpoint in Postman, get a 200 response, and call it done. But on a real device, with a slower network, a different OS version, and actual UI rendering, the behavior is completely different.
This is the gap between "the API works" and "the app works." Testing one doesn't guarantee the other.
How to catch API failures before your users do
Testing APIs in isolation (with Postman, curl, or a unit test) tells you whether the endpoint returns the right data. That's necessary but not sufficient. You also need to verify that the app handles that data correctly on screen, on a real device, under real conditions.
That means running end-to-end tests that cover the full flow: the API call, the response parsing, and the UI update. If the payment API returns a success but the confirmation screen doesn't render, your API test passed but the user still had a broken experience.
Before: QA manually hits the API in Postman, confirms the response looks right, then manually opens the app on a device and taps through the flow. This takes 15 minutes per scenario and doesn't scale across devices or OS versions.
After: You write a test in plain English: "Tap Pay Now, wait for confirmation screen, validate 'Payment successful' is visible." A Vision AI engine executes it on a real device, looking at the actual screen the way a user would. If the API returns a 200 but the UI doesn't update, the test catches it. If the API is slow and the button stays frozen, the test catches that too.
That's how Drizz handles it. You describe the user flow, and the Vision AI runs it on real Android and iOS devices. It doesn't rely on element selectors or hardcoded waits, so it doesn't break when the UI changes. It tests what the user actually sees, which is where API failures become visible.
If you're building an app that depends on APIs (and almost every app does), testing the API alone isn't enough. You need to test the full path from API response to screen. That's the difference between "the API works" and "the app works."
FAQ
What is an API in simple terms?
An API is a set of rules that lets two pieces of software communicate. One system sends a request, the other sends a response. When your phone's weather app shows the forecast, it's calling a weather API to get that data from a remote server.
What are the most common types of APIs?
REST, GraphQL, and webhook APIs are the three you'll encounter most often. REST uses standard HTTP methods and returns JSON. GraphQL lets the client request specific fields. Webhooks push data to your app when an event happens, instead of waiting for the app to ask.
What is a REST API example?
The Stripe payment API is a common REST example. You send a POST request with an amount and currency, and the API processes the charge and returns a confirmation. Google Maps, Twitter, and OpenWeatherMap are other well-known REST APIs.
How do I test an API?
You can test an API in isolation using tools like Postman or curl to send requests and inspect responses. For mobile apps, you also need end-to-end tests that verify the app handles the API response correctly on a real device, not just that the endpoint returns a 200.
Why do APIs fail in mobile apps even when they work in Postman?
Network conditions on real devices are different from your development machine. Slower connections, background processes, OS-level throttling, and screen rendering all introduce variables that don't exist when you test the API in isolation. A 200 response doesn't mean the app displayed the data correctly.
What's the difference between REST and GraphQL?
REST returns a fixed set of fields for each endpoint. If you need data from three endpoints, you make three requests. GraphQL lets you write a single query that returns exactly the fields you need from multiple resources in one request. GraphQL is more efficient for mobile apps that need to minimize network calls.
