API and Database Testing
A screen that saves without error can still write a wrong figure or a duplicate row underneath it. GullySystem tests API endpoints and checks the resulting database rows together, for teams whose software moves money, stock or records.
Why the Screen Is Not Enough
An API can return a success response while writing incomplete or duplicate data, and a screen can display a correct-looking total built from a query that silently dropped a row. Testing only what appears on screen misses both. We test the request and response directly, then check what actually landed in the database, because that is where the expensive mistakes hide.
What API Testing Covers
Valid and Invalid Input
Correct requests, missing fields, wrong data types, and values outside any stated limit.
Authentication and Permissions
Whether a token from one user role can reach data or actions meant for another.
Error Codes and Messages
Whether failures return a code and message a developer can act on, rather than a generic server error.
Repeated and Concurrent Calls
The same request sent twice, or two requests arriving at the same moment, checked for duplicate records or lost updates.
What Database Verification Covers
- Whether the value shown on screen matches what is actually stored, not just what the API most recently returned
- Whether a failed or retried action left an orphan or duplicate row behind
- Whether related tables stayed consistent after an update, such as a stock count and an order line moving together
- Whether deleted or archived records are actually removed from active queries rather than merely hidden on screen
An Insurance Broker's Policy System, as an Example
A broker's renewal API is tested for two agents updating the same policy at the same moment, a premium recalculation triggered twice by a retried request, and a cancelled policy that must stop appearing in active renewal counts while its history remains intact. The check that matters is not the confirmation message the agent sees — it is whether the policy table, the commission table and the renewal report all agree afterwards.
Frequently asked questions
Do you test REST and GraphQL APIs the same way?
The principles are the same — valid and invalid input, permissions, error handling and the data left behind — though the specific test structure differs. REST endpoints are tested individually with saved request collections; GraphQL queries and mutations are tested for what fields they expose to which roles.
Which databases can you verify against?
Relational databases such as MySQL, PostgreSQL and SQL Server, and common NoSQL stores, are all workable, provided we are given read access to a test copy and an understanding of the schema for the tables in scope.
Will you need write access to our database?
Read access is usually enough, since the goal is to confirm what an action actually stored. Write access is only needed where we are preparing specific test data conditions, and is always scoped to a test or staging copy, never a live production database.
What drives the cost of API and database testing?
The number of endpoints and roles in scope, how many tables need cross-checking per action, whether concurrency and retry scenarios are included, and whether the checks are automated into a reusable collection or run once.
What decides how long API and database testing takes?
How many endpoints and permission combinations exist, how complex the underlying data relationships are, and how quickly a stable API documentation or specification is available to test against.
Can you test our API without documentation?
It slows the work but does not stop it. Where no specification exists, we work from the frontend that calls the API and from a walkthrough with a developer who knows the intended behaviour, and note where the lack of documentation itself is a risk worth raising.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private