Skip to contentTalk to us
العربيةLog inStart free
API testing

Your API answers. Does it answer correctly?

Your mobile app, your store and your partners all depend on the API, and a small change in it breaks them without showing on any screen. Upload the description file and the QA engineer reads the operations and proposes the checks, then runs them and shows you which request returned something unexpected, with the request and the response exactly as they were.

Start freeHow it works
Straight from the description fileSecrets are masked in evidencePart of the paid plans
Why now

API bugs do not show on a screen

1

A field was renamed and the app broke

A small change to a response looks harmless in the code, then the mobile app stops showing orders. Nobody notices until customers complain.

2

One user sees another’s data

The request succeeds and returns data, but it is another customer’s. A “does it respond?” check will not catch that. A “does it return only what this user may see?” check will.

3

Manual checks do not get repeated

The developer tries a few requests by hand before a release and that is that. Next release nobody repeats them all, and an old bug comes back.

1The checks

From the description file to checks you review

Upload or paste your API description file, in OpenAPI or Swagger format, written as JSON or YAML. The QA engineer reads the operations and proposes what is worth checking for each: is the status right, are the required fields present with the right type, is incomplete data rejected with a message that makes sense, and is a user stopped from reading someone else’s data. When you allow writes it tries a full sequence: create a record, read it back, then delete it.

  • Status, fields and their types
  • Permissions and error messages
  • Create, read, delete, with your permission
2Saved cases

Checks written once and re-run with every release

Every check is saved as a case with readable steps: the request that is sent and what is expected in the response. Group them into suites, edit them yourself when the API changes, and run them all with one press after every release. Each case keeps its history in front of you: when it passed and when it failed.

  • Readable steps, not code to maintain
  • Suites you run with one press
  • Pass and fail history per case
3Evidence

The request and the response as they were, minus the secrets

When a check fails you do not just get “failed”. You get a bug card with the request that was sent, the response that came back, what was expected, and what it means for whoever uses the API. Access keys, tokens and passwords are masked before any evidence is stored, so you can share the card with your developer without worry.

  • Request and response attached to each bug
  • Keys and tokens masked
  • Closed after the retest passes
Examples

What you say, and what the QA engineer checks

A store’s orders API

It creates a test order, reads it back and checks the total and the status, then deletes it. It also tries creating an order with no address to make sure it is rejected with a clear message.

Make sure creating, reading and cancelling an order work, and that an incomplete order is rejected with a message a developer can understand.

Each customer’s data stays theirs

With two test accounts it tries to read the second one’s invoices using the first. The request should be refused; if the data comes back, that is a high-severity bug.

Check that a customer cannot see another customer’s invoices, even if they change the number in the request.

Before a new mobile app release

It re-runs the saved suite against the API the app depends on and compares the result with the previous run: what is new and what has come back.

Re-run all the API checks and tell me whether anything that worked last release is now broken.
The steps

How to test your API in five steps

From the description file to a suite you re-run whenever you like.

  1. 1

    Add the API’s address

    In “QA Engineer” choose “Test an API” and enter its address. By adding it you confirm it is yours or that you are allowed to test it, and it is ready straight away.

  2. 2

    Upload the description file

    Upload or paste the OpenAPI or Swagger file, as JSON or YAML. From it the QA engineer learns which operations exist and what they are meant to return.

  3. 3

    Add a test key and set what is allowed

    Add an access key meant for testing; it is stored encrypted. Then decide: read-only, or may it create and delete test records.

  4. 4

    Review the proposed checks

    The QA engineer shows the cases grouped with a priority each, and flags the ones that create data. Switch off what you do not want, then run.

  5. 5

    Read the result and re-run after each release

    Each failed check is a card with the request and the response. Retest after the fix, and keep the suite to run with every new release.

Plainly: what you should know

Not load testingIt checks that responses are correct; it does not measure how many requests per second the API can take. The request rate is capped so your server is not strained.
Not a security auditIt checks the permission rules you describe, such as keeping one customer out of another’s data. It is not a penetration test and no substitute for a specialist security review.
Needs the description fileThe more accurate the description file, the more accurate the checks. Anything the file leaves out you can add yourself as a manual case.
Writes only with permissionChecks that create or delete data are skipped unless you allow them. Use a staging environment and a test key for those where you can.
FAQ

Questions people ask

What is API testing?
It is checking that the interface your app uses to talk to the server returns what it should: the right status, complete fields of the right type, error messages that make sense, and never one user’s data to another. It is done by sending requests directly, with no screens involved.
How do I test an API without writing code?
Upload your API description file to Fanann’s QA engineer. It reads the operations and proposes checks as readable steps; you review and run them. You write no code, and you can edit any case from a simple form.
Which description file formats does Fanann accept?
OpenAPI and Swagger files, written as JSON or YAML. You upload the file or paste its contents.
Does it test API permissions?
Yes. It checks the rules that matter to you, such as a request without sign-in being refused and one user being unable to read or change another’s data. That is a check of permission behaviour, not a full security audit.
Are my API keys safe during testing?
Test keys are stored encrypted and are not shown again after you enter them. Keys, tokens and passwords are masked out of requests and responses before they are stored as evidence or shown in a report.
Does Fanann do API load testing?
No. The QA engineer checks that the API behaves correctly, not how it holds up under load. Load testing is outside what it offers today.
Is API testing in Fanann free?
Signing up to Fanann is free, and the QA engineer is part of the paid plans. Which kinds of testing you get, and scheduled runs, depend on your plan.
QA Engineer

What else can the QA engineer test for you?

QA Engineer

The main page: an AI QA engineer that plans tests, runs them in a real browser, documents every bug with evidence and tells you whether your app is ready to launch.

Meet the QA engineer

Website testing

Is your site built outside Fanann? Add its address and have the QA engineer test its pages, forms and flows in a real browser.

See the details

Regression testing

Every test case is saved and re-run. After any change you know in minutes whether what worked still works, and when it broke.

See the details

Bug tracking

Every bug is a card with impact, steps, expected vs actual and a screenshot, and it stays open until a retest proves it fixed.

See the details

Test before launch

Built your app with Fanann? Test it from the publish window itself, ask Fanann to fix what turns up, then publish knowing where it stands.

See the details

For restaurants & booking

Two guests, one table, 7 pm: how the QA engineer finds the double booking before your guests do.

See the details

Guides to read before you test

What is software testing?

An explanation for business owners, without jargon: what gets tested, the kinds of testing that actually matter to you, and when manual testing is enough and when it is not.

Read the guide

Website testing checklist

A practical list to go through before you announce your site: sign-up, forms, checkout, mobile, Arabic, messages and what comes after launch.

Read the guide

How to write a bug report

A ready template and examples: a clear title, steps that reproduce the bug, expected vs actual, evidence, and how to set severity without exaggerating.

Read the guide
Regression testingWhat is software testing?How to write a bug reportPlans and pricing
From the blog

Guides to testing and AI QA

All Testing & AI QA guides
PASSPASSBUGPASSPASSWhat is an AI QA agent? How it tests your site like a careful person9 min readAn AI product team in one place: plan, build and test without hiring11 min readPASSPASSBUGPASSPASSAI QA agent or a human tester: who should test what?9 min read

Know your API is sound before your app tells you otherwise.

Upload the description file, review the proposed checks and run them after every release. The QA engineer is part of the paid plans, and signing up is free.