API Tester

Send API requests, start from a ready template, organize reusable tests, work with a team, and understand when an API changes.

• Send your first request - Send a safe GET request and read the answer. No account needed.
• Start from a ready API template - Make a working project, suite or monitor on the built-in sandbox in one press.
• Build and send a single request - Set the method, URL, headers, body and variables, send it and save it.
• Build a request and its checks - Fill a request in, say what a pass means with checks, and keep values for the next request.
• Use variables and data sets - Write {{name}} once and let the workspace, environment, earlier steps or a data set fill it in.
• Send a request to localhost from your browser - Test an API on your own machine or network with the {{brand}} browser extension.
• Reach a private API without a browser: the CLI agent - Send a request to localhost or a private network through a small program on your own machine.
• Paste a cURL command, address or capture - Turn what you paste into search into a request or a project.
• Paste a link and get a tested API - Paste the address of an OpenAPI document, an API address or a cURL command: {{brand}} sends the safe reads, writes checks from each answer and saves it all as a suite. Before you sign up, try it on the sandbox.
• Import a request with Copy as cURL - Copy a request from the browser Network panel and open it in API Tester.
• Import from a HAR capture or an OpenAPI address - What each import keeps, the limits on fetching a document, and what to do when it fails.
• Bring requests from Insomnia or Bruno - Import an Insomnia export or a Bruno collection with its folders, environments and checks, see a preview first, and undo it from History.
• Test a SOAP service from its WSDL - Import a SOAP service's WSDL and get one ready request per operation, with its envelope, action and checks written for you.
• Organize requests in folders and projects - The four levels, where shared content appears, and how to bring requests in.
• Find and run requests across projects - Use the API catalog and search to find requests, assign who is responsible and run them in bulk.
• Choose how a request signs in - Set a project's default profile and decide what each request and environment inherits.
• Add an authentication profile - Save a bearer token, user name and password, API key or OAuth client once on a project.
• Share a project and choose who can open it - Who can open an organization's project, the five levels from View to Manage, and running against production at the Run level.
• Share a project in your personal workspace - Give people a project or folder of your own by email address, and see how a folder passes access to everything below it.
• Run a whole project - Run every saved request or one test group and read the summary.
• Set response-time bands - Decide what fast, slow and too slow mean for a project or one request.
• Compare two runs of a request - Set two runs side by side to see what changed in the response.
• Chain requests in a test suite - Build a suite of ordered steps, run it and read the result.
• Record a regression suite - Turn a Browser Sync recording into a suite that replays what you did, in order.
• Add expectations and extract values - Decide when a step passes and carry a value from one step into the next.
• Run your suites in a pipeline with the CLI - Run a suite or a whole project from your own CI pipeline, and see the result in {{brand}}.
• Let a coding agent work with {{brand}}: kamocore mcp - kamocore mcp gives a coding agent on your machine {{brand}}'s tools: read projects, runs and failures, run a suite you named, and - only when you allow writes - file a bug with its evidence.
• Start the affected tests after a deploy - Tell {{brand}} from your pipeline that an API was deployed, and it runs the suites the change touches.
• Run only the tests a change touches - Add --affected to kamocore run, and a pull request runs only the suites its changed files touch - every suite, with the reason, when it cannot tell.
• Run a load test - Send the same request many times at once and read the response-time spread.
• Judge load tests against a baseline - Save a run as the baseline, so later runs fail when they get slower.
• Run whole projects at a set time - Monitors that run every saved request of a project, a team's projects or the organization's at a set time.
• Monitor an API and get alerts - Check a request or a suite every few minutes, see its health, and hear when it fails and recovers.
• Publish a status page for your customers - Show the people who use your API how your monitors are doing, on a public page with 90 days of history - never a request, an address or a body.
• See what happened just before a request began failing - When a saved request turns red, its notice says what happened just before - a deploy, a new API version or an edit - and offers the one next step.
• Security scan, access matrix and webhook inbox - Scan a project for security gaps, check who can reach what, catch webhooks and try bad inputs. "Test" › "Security" and "Build" › "Mocks, streams & docs" hold them.
• Save a response as an example - Keep a response on a saved request, masked, for a mock server to answer with.
• Answer from a mock server - Give a project a public address that answers like your API, from its saved examples.
• Publish API documentation and a changelog - Give a project's documentation and its changelog an address to share, by private link or public.
• Use the {{brand}} API reference - Read every {{brand}} API route an access token can call, and try one with your own token.
• Test a WebSocket, an event stream or a gRPC service - Connect to a WebSocket, a Server-Sent Events address or a gRPC method, send messages and check what comes back.
• Test your own MCP server - Connect an MCP server, see every tool an AI agent would see, call a tool with checks, and be told when a tool changes or looks unsafe.
• Comment on a request, a suite, a run or a change - Leave a note for the next person on a saved request, a suite, one run or an API change, and tell the people who should see it.
• Keep a project as files in Git - Export a project as plain YAML files, one per request, and import them back with a preview of what changes.
• Draft a suite or test data with the assistant - Ask for a suite with checks, or rows of test data, and confirm the preview before anything is saved.
• Can we ship? - release readiness - One verdict for a project - Ready, Risky or Blocked - with the reason behind it and a one-click fix for each.
• Record a release and share its proof - Freeze what was true when you released - the verdict, the suites, the API changes and every decision - and share it as proof with a link that ends.
• Write release notes from a release record - Get customer and team release notes drafted from the release's own records - finished cards, API changes and verified design steps - edit them, export them and share them by link.
• Review an API change - See how a response changed, how risky it is, and accept or ignore it.
• Catch breaking changes in a new API version - Compare a new OpenAPI version with the project's contract, see what breaks and what it touches, and let verification decide it.
• Follow changes over time - How candidates chain during a testing session and how release history compares accepted versions.
• Read the change summary - A plain-numbers status update of what is watched, what changed and how risky it was.
• Read Insights and reliability - Your testing over time: activity, speed, coverage, and which requests pass, flip or fail together.
• Find flaky checks and put them in quarantine - See which saved requests and suite cases flip between pass and fail, and quarantine one with an owner so its results stop counting as evidence until it is fixed.
• See who tested what - Use Traceability to see what was tested, by whom and when, and how much of a project is covered.
• Attach evidence and export reports - Add a screenshot or log to a run, and export an Excel history or Word report.
• Control what a run keeps - Choose whether runs keep status and timing only or masked content too, and how long.
• Import and export a project - Move a project as a {{brand}} package, OpenAPI, Postman or Excel file.
• How OpenAPI and Postman files convert - What becomes a request, an environment, a check or a placeholder when you import or export.
• Build a verification workflow - Define the stages an API must pass before it counts as verified.
• Choose which APIs follow a workflow - Set policies, what each kind of change asks for, and the rules for restarts and expiry.
• Verify an API - See where every API stands, start a verification and know what happens when it changes.
• Review and decide a verification - Approve, request changes or reject, and attach the evidence behind your decision.
• Use automated verification checks - What each automated check reads, and what happens when one fails.
• Fix a request that does not work - What common errors mean, why a button or history is missing, and who decides access.