Automation and testing

Once a request works, make it work for you. Echo automates the repetitive parts: running suites, chaining calls, faking dependencies and checking on a schedule.

Run a whole collection

The collection runner executes a collection end to end:

  1. Choose the collection and set the number of iterations.
  2. Add a delay between requests if the target API needs breathing room.
  3. Turn on abort-on-error if one failure should stop the run.
  4. Start the run and watch results arrive live.

The runner helps you check an API after a deploy or reproduce a failure across several iterations. Load a CSV file with column headers or a JSON array of objects to run the collection with different input data. Each row supplies values for one iteration.

When the run finishes, export a JUnit XML report for your test tools or an HTML report to read and share. The run history keeps the data file name and row count so you can identify how a run was prepared.

Chain requests without code

Request chains are declarative: no scripting needed. A chain runs steps in order, and each step can extract values from a response with JSONPath and pass them to later steps. Sign in, grab the token, create a resource, verify it, all as one chain.

Steps can also carry conditions, so a chain can branch on what the API actually returned instead of blindly running everything.

Choose where your mock runs

When a real dependency is not ready, a mock lets the frontend team keep working and lets you rehearse timeouts and error codes. Echo matches routes with path patterns, supports static or contract responses, and lets you set delay and status per route.

The desktop can intercept requests sent inside Echo for free. For a URL that another application or teammate can call, use a paid Echo plan to publish a synced mock through the public hosting panel in Maestro. Publishing a team mock needs Echo/ManageHosting; the owner of a personal space can publish its own mock on a paid plan. A public hosted mock keeps responding without the desktop running. See public mock hosting for the publishing steps, public URL access and operational controls.

For rules inside your own .NET application, use Mock.Client or Mock.Server and an application key with ServeMocks on a paid Echo plan. That paid rules feed is separate from the public hosted URL; your application uses its own address.

Desktop mocks also support gRPC responses and WebSocket message sequences. They answer requests made inside Echo. They do not open a network listener or provide a gRPC or WebSocket address for another application; public mock hosting serves HTTP requests.

Check contracts as well as responses

A contract describes the data shape that an application provides or consumes. Publish versions and compare their compatibility in the direction that matters to your application. The Contracts and Testing packages connect publication and validation to .NET automation.

Schedule runs

Choose where each schedule runs. Desktop schedules need Echo to stay open. Hosted schedules run on Gapfy's servers and continue after you close the app; they require a paid Echo plan and permission to use hosted schedules.

Hosted schedules support HTTP requests and GraphQL query and mutation operations, with at least five minutes between runs. Choose the environment, save the schedule and check that Echo confirms it was scheduled on the server. Syncing a desktop schedule alone does not switch it to hosted execution. Maestro shows hosted schedule results and synced collection run summaries.

Script when you want to

For the cases that outgrow declarative chains, Echo supports pre-request and post-request JavaScript with the familiar pm.* API, including assertions. If you have written Postman scripts before, the approach is familiar: assert on status codes, response bodies and headers, and fail the run when reality disagrees with expectations.

Reach for chains first because they are easier to read and maintain, and use scripts where you need custom logic.

Next steps