Top API Testing Interview Questions and Answers

API testing means checking if the communication between different software systems works correctly, like making sure data is sent and received as expected. For example, testing if a weather app correctly gets data from a weather service by sending a request and checking the response.

REST APIs that use URLs and HTTP methods, and SOAP APIs that rely on XML messages.

For example, we can use a REST API to get user info from a website or a SOAP API to process payments.

We use GET, POST, PUT, and DELETE generally for API testing. These methods tell the API what you want to do.

Like, you use GET when you want to grab info, POST to add new stuff, PUT if you’re updating something, and DELETE when you want to remove data.

Both update data, but in different ways.

For example, use PUT to replace a whole user profile, and PATCH to change just the user’s email.

Postman is great for manual testing, while tools like REST Assured or SoapUI help automate tests.

They show if the API call worked or failed.

For example, 200 means success (like data was fetched), 404 means not found, and 500 means something broke on the server.

Headers carry extra info between the client and the server. For example, in a request, headers can include an API key for access. In a response, they can show the content type, like JSON.

We do API authentication to keep everything safe. Only the right people should hit your API. For example, like when you send a token with your request, so the system knows it’s you and not some random user. 

It's the end of the URL where our API listens for requests. For example, in api.wac.com/employees, “/employees” is the endpoint you call to get or manage user data.

All web services are APIs, but not all APIs are web services. For example, a web service always works over a network (like HTTP), but an API can also work inside apps without a network.

API authentication makes sure only the right users or systems can access the API. For example, 

API Key: We send a unique key in the header like x-api-key.
Basic Auth: We pass a username and password, often base64 encoded.
Bearer Token (OAuth): We use a token like Authorization: Bearer <token>.

Each method keeps the API safe in a different way.

It checks if the API response follows the expected structure. For example, in Postman, you can add a test script using tv4 or ajv to match the response against a JSON schema, like making sure all keys and data types are correct.

For instance, you want to make sure the response has an “id” as a number and a “name” as a string. If it does, the test passes. 

In Postman, the pm.response.to.have.jsonSchema() method uses Ajv (a JSON schema validator) behind the scenes to check if the response fits the schema you define. You don’t have to add Ajv manually. Postman handles it for you.

So, what happens here? The test checks if the API response is an object with two properties:

• id, which must be a number
• name, which must be a string

If the response has these properties and types, the test passes. Otherwise, it fails.

With tv4 or ajv

The parts that we see in a URL are path parameters. Query parameters come after the question mark in a URL. For example,

In api.test.com/employees/abc?active=true

abc is a path parameter (it points to a specific employee), and active=true is a query parameter (it filters or changes the request).

You check how fast and stable the API responds under different loads. For example, using tools like JMeter or LoadRunner, you send many requests at once to see if the API stays fast and doesn’t crash.

It helps manage changes without breaking existing users. For example, if you update an API, you keep the old version (like v1) for current users and release a new one (like v2) with improvements, so everyone can work without issues.

API mocking creates fake API responses for testing when the real API isn’t ready. For example, if the API isn’t built yet, you can set up mock responses that look real to test your app without waiting.

Synchronous APIs wait for a response before moving on. Asynchronous APIs don’t wait and handle responses later. For example,  with a synchronous API, your app waits for data before continuing. With asynchronous, your app keeps working and deals with the response whenever it arrives.

Sometimes APIs change, and your tests stop working. Otherwise, the docs don’t tell you everything, so you have to guess what’s going on. For example, once an api update changes a response format, then we have to spend time figuring out why our tests fail.

We must make sure to write simple test cases and try different kinds of data. Both valid and invalid. We should also automate tests when possible to avoid repeating the same work.

For example, we can test with normal and wrong inputs, watch the response times, and use tools like Postman or JMeter to speed things up.

CSRF is when a hacker tricks your browser into doing something you didn’t ask for, like sending a request while you’re still logged in.

For example,  if you’re logged into a site, an attacker might trick your browser into clicking a hidden link that changes your account details without you knowing.

API protocols are rules that define how data is sent and received between systems.

For example, REST uses simple URLs and HTTP methods like GET or POST. SOAP uses XML messages with strict rules and security features. GraphQL lets you ask exactly for the data you want in one request.

We handle dynamic data by capturing values from one response and using them in the next requests. For example, if an API gives a user ID after creating a user, we save that ID and use it to get or update the same user later in the test.

We first get an access token using OAuth, then include that token in API requests to access protected data. For example, we request a token with our credentials, then add Authorization: Bearer <token> in the API headers to test endpoints that require login.

We add automated API tests to run whenever code changes, so issues get caught early. For example, when developers push code, tools like Jenkins run Postman or other API tests automatically before deploying to make sure everything works.

We run the same API tests multiple times with different data sets using Newman and a data file. For example, we create a CSV or JSON file with different inputs, then tell Newman to use that file to send requests with each set of data automatically.

We isolate the third-party parts by using mocks or stubs, so tests don’t fail if the external service is down. For example, if the API calls a payment gateway, we create fake responses to test our app without relying on the real service every time.

Contract testing ensures that different microservices agree on the data they send and receive. For example, if one service expects a user object with a name and email, contract testing checks that the service sending the data follows that exactly, so nothing breaks.

We test if the API returns data in chunks and lets us get all pages correctly. For example, if an API returns 10 items per page, we check the first page, then request the next pages until all data is fetched without errors.

We test APIs first in the dev environment to catch early issues, then in staging to mimic real conditions, and carefully in prod to avoid problems. For example, we run all tests in dev, then repeat in staging with real kind of data, and finally do limited checks in the production environment to ensure everything works smoothly.

We test new API versions to make sure old clients still work without breaking. For example, if a new API version changes a response, we check that old apps can still use the previous format without errors.

REST is the set of rules for designing APIs. RESTful means an API that follows those REST rules. For example, if an API uses HTTP methods properly and URLs to represent resources, it’s called RESTful. If it doesn’t follow these rules fully, it’s just called REST.

REST Example:

An API that uses /employees to get all employees and /employees/1 to get the employee with ID 1, using GET, POST, PUT, and DELETE methods.

RESTful Example:

An API that follows REST rules strictly, like using the HTTP protocol correctly and stateless requests, e.g.,

GET/employees to list employees,
POST/employees to add employees.

In short, REST is an idea, and RESTful is doing it right.