Types of Tests

API Testing: Verify Your Data Exchanges Before the Interface

An API that returns an empty field, a poorly handled error code, or a date format that changes. API testing catches these issues right at the source, without waiting for them to show up on a screen.

REST and SOAPVerification of Response ContentWithout writing any code

API test block in the no-code editor Mr Suricate, method, authentication, and expected response codes

They trust us

3 million scenario runs per month100+ clients15 types of tests covered

Retail, banking, manufacturing, transportation, services. Hosting in the European Union, French-language support, personalized assistance during the startup phase.

In a nutshell

An API test verifies communication between systems without going through the user interface: the request is sent, the response is received, and its content matches what is expected. It detects a breach of contract or a missing field before a screen displays it incorrectly, and runs in just a few seconds.

An API crashes without displaying anything

A service now returns an empty string instead of zero, and three screens later, the cart total is incorrect. Or the field still exists but has been renamed, and the front end ignores this without warning. These issues don’t cause any visible errors until someone actually looks at the response itself.

The return code alone is not enough

A score of 200 does not mean the answer is correct. The test checks the content: fields are present, expected data types are met, and values are consistent.

Consecutive calls

Completing one call triggers the next one. Create a shopping cart, add a product to it, and confirm the order: the sequence is tested as a single sequence.

Authentication and Tokens

In both revenue and production

The same calls replayed in each environment, along with the corresponding variables and datasets.

Your calls are verified as soon as they are integrated

Your API tests are triggered from your CI, run on your production environments, and report back to where your teams are already working. No re-tooling required.

1 Triggering Your tools stay in control

GitLab
Jenkins
Microsoft Azure
API Call
Planning

2 Execution

Your scripts run on your production environments

Web Tour
Native iOS and Android Apps
Real Mobile Farms
APIs and Internal Feeds

3 Restitution The results are delivered right to your workplace

Jira
Slack
SMS
Webhook
API

And maintenance that stands the test of time

Reusable blocksA change updates all scenarios that use it
AI-Assisted CorrectionSuggested corrections for scenarios with errors
Grouping IncidentsSimilar anomalies are processed only once

What the API Test Changes, Line by Line

Tests Using Only the InterfaceWith API tests

Tests Using Only the Interface

With API tests

The break appears three screens later.

It reveals itself through the call that brought it into being.

You have to go through the entire process to test a service.

The call connects immediately, within a few seconds.

A format change is successful if the screen doesn't crash.

The review focuses on the content of the response.

Error cases are rarely tested.

4xx and 5xx codes are included in the scenarios.

The back end can only be tested once the front end has been delivered.

Services are tested as soon as they are available.

The diagnostic data is sent from the screen back to the department.

He's starting right from the right place.

ResultCommunication errors detected at the source, before they become a visible bug in a customer journey.

Scenario-Based Testing

The call played during the round, along with the round data

Assertions about the response content, not just the return code

I play it again with every delivery without even thinking about it

Collection in an API client, such as Postman

Perfect for exploring and debugging

Lives next to the course, not on it

Its maintenance depends on the person who created it

In practice: Verify that the total (including tax) returned by the shopping cart API call matches the amount displayed on the screen, or that the response conforms to the expected JSON schema, field by field. You provide the schema, and the test flags any non-compliance without interrupting the rest of the user flow.

assertion, mock, integration: the definitions are in the QA glossary.

Detailed comparison with Postman: Mr Suricate vs. Postman.

WHITE PAPER · TEST AUTOMATIONWhat if your bugs no longer cost your business anything?The true cost of bugs originating from a third-party service, and the fundamentals to establish before automating.

Download the white paper

“What convinced me was the no-code approach: our QA engineer got the hang of the tool in just a few days. The tangible result: fewer bugs in production and smoother deployments.”

Arnaud TrotignonCTO, Optivalue

You make the assertions, or we make them with you

With Mr Suricate, your QA team isn't replaced—it's strengthened. You choose what to handle in-house and what to outsource: creating test scenarios, running them, or maintaining them over time.

1Identification of critical paths, front-end and back-end
2Writing Tests Without Code
3Continuous monitoring and alerts
4Scenario Maintenance and Development

ResultYou gain broader coverage without increasing your teams’ workload. And if you’d rather delegate everything, QA outsourcing takes over.

GO FURTHER

Other Types of Tests

Fifteen types of tests, four categories. Each one answers a different question about your application.

End-to-End TestingThe entire process, from start to finish, including third-party systems.Learn more Functional testingVerify that a feature produces the expected result from the user’s perspective.Learn more Non-regression testingRe-run all validated test cases before each deployment.Learn more Performance testingThe actual response time of your user flows, continuously measured and compared to your thresholds.Learn more Production MonitoringThe same scenarios replayed in production, continuously, with alerts triggered at the first failure.Learn more Data Layer TestingEvents sent to your tagging plan, verified at every stage of the journey.Learn more Security testingVerify what a user can actually access: permissions by profile, sessions, authentication, HTTPS.Learn more The 15 types of testsThe big picture: four categories, fifteen types, and where to start based on your situation.Learn more

Is there a term you don't understand? The automated testing glossary defines it.

YOUR QUESTIONS

Frequently Asked Questions

The most common questions we get about API testing.

What types of APIs are covered?

Web APIs accessible via HTTP, whether REST or SOAP, as well as incoming webhooks. The scenario simulates the call, including its headers and body, and then checks the return code and the response content.

Do you need to write code to create an API test?

No. The call and the checks are built by assembling blocks, like an interface script. This is what allows a non-developer tester to cover the services without relying on the back-end team.

Can we chain multiple calls together in a single scenario?

Yes, and that's the most useful case. The value returned by a call—such as a shopping cart ID or an authentication token—is reused in subsequent calls. The entire sequence becomes a single scenario.

How are tokens and secrets managed?

Secrets are encrypted at rest and are never revealed in plain text. Authentication tokens are obtained within the scenario itself, which also allows for testing their renewal and expiration.

Can API tests and interface tests be combined?

Yes, and that's often the right way to do it. A script can retrieve data via an API to save time, then verify the result on the screen. The actual workflow goes through both steps, and so does the test.

Is it possible to validate the structure of a response, not just its content?

Yes. A JSON schema validation block checks that the response complies with the expected contract: fields present, types, and allowed values. A field that has been renamed or changed from a number to a string will cause the test to fail, even if the call returns a 200 status code.

Is SOAP covered?

Yes, a dedicated module sends SOAP requests and reports the error when the service returns an error. Environments that continue to use legacy services therefore do not need a separate tool.

Can we test anything other than a suspected case?

Yes, and that’s often the most useful option. The expected response code is configurable: you can require a 403 to verify that a profile does not have access to a resource, or a 404 to validate an error condition. Technical error codes to be returned must be declared separately.

What do we gain from an execution?

The response code, body, and headers are stored in variables that can be reused in subsequent steps, and the request and response logs can be downloaded from the report. A performance threshold per request also allows a call that is too slow to be rejected.

How can you avoid false positives on a call chain?

By isolating the usual causes: a dedicated dataset, an explicit wait between two dependent calls, and an environment whose state is known. A failure that does not recur on the second execution is a sign of instability, not an application defect.

Do you only believe what you see?

A 30-minute demo of your own app. You'll see one of your workflows automated in real time, without writing any code.