API Testing

This one might sound a bit unusual but it works really well. Our agents can make HTTP calls, which means you can point them at your public API documentation and tell them to verify whether it is still correct.

This solves a classic problem in a lot of organizations: API documentation drifting out of sync with the actual API. Endpoints get renamed, parameters change, response formats evolve, but the docs stay the same. By letting an agent read your API docs and actually try the examples, you catch these inconsistencies before your users do.

API Docs GET /users POST /users DELETE /users/:id GET /orders POST /orders ... Aiqaramba Journey: Users CRUD create → read → delete → verify Journey: Orders CRUD create → read → update → cleanup Journey: Auth flow login → token → refresh → logout Results ✓ Users: docs match ✗ Orders: wrong status ✗ Auth: missing field Docs ≠ actual behavior

How we would set it up

Most applications that follow a REST-like design have endpoints scoped to entities. You have your users, your orders, your products, whatever your domain is. Each entity typically has a handful of endpoints: GET to list or read, POST to create, PUT or PATCH to update, DELETE to remove. Sometimes there are extra action endpoints like POST /users/:id/verify.

We suggest setting up one journey per entity group. A "Users CRUD" journey, an "Orders CRUD" journey, and so on. This way when a journey fails, you immediately know which part of your API has drifted from the documentation.

The tricky part is dependencies. To test DELETE /users/:id you first need a user to exist. Each journey should handle its own setup: create the entity, test the operations, then clean up after itself. This makes the journeys self-contained and repeatable. A journey that leaves data behind will eventually collide with itself on the next run.

  • One journey per entity. Group related endpoints together. A "Users" journey creates a user, reads it, updates it, deletes it, and verifies the deletion. This mirrors how the API is structured in the docs.
  • Self-contained and repeatable. Each journey should create what it needs, test it, and clean up. No shared state between journeys. This means you can run them in any order and as often as you want.
  • Run after deployments. API tests are most useful right after you deploy. Set up a schedule or trigger them from your CI pipeline to catch documentation drift before it reaches your users.

Generate with your coding agent

Fill in the details below and copy the prompt into your coding agent.

Prompt