Debugging guides
Requestly API mocking vs a saved browser state
You have a rule that makes the quote API reject a booking. It works. The response is exactly what you need. The annoying part is opening the right customer, selecting the dates, adding two rooms and changing the second guest’s age every time you edit the form.
Keep the rule. The question is how much of the form you still have to prepare around it.
The booking example below is synthetic; it makes no performance claim about either product.
Requestly already handles recorded mocks
Requestly’s HTTP Interceptor supports response modification and API mocking. The documented bulk workflow is a Desktop feature: save captured traffic as a session, select requests and create rules. It offers matching choices for URLs, paths and queries, with payload filtering for GraphQL selection. 1, 2
Requestly also records bug-report sessions with browser activity and diagnostics. The comparison below concerns repeated setup, not an alleged absence of recording. 3
For a narrow response experiment, test the Requestly rule first. In the recorded-session path, use Create Mocks from this Session, select the required requests and inspect the generated matching rules before retracing the form. 1
Make the response experiment precise
Suppose the booking API returns HTTP 422 with the following body:
{
"code": "GUEST_AGE_REQUIRED",
"roomIndex": 1,
"guestIndex": 0,
"message": "Enter the second room's guest age"
}The hypothetical bug is that the UI highlights the first room and discards the second room’s entered values. To investigate it, the mocked status and body must agree with the code path under test. Returning the same JSON with HTTP 200 could test something else.
Match the intended request narrowly. Record its method, path, relevant query and payload conditions. Confirm the rule actually applied. Then check both the location of the validation error and the retained fields; seeing an error banner alone does not test the bug.
Requestly’s Modify Response controls are designed for this kind of response experiment. Its documentation describes static and dynamic modifications; use the approach that fits the request rather than rewriting the application for the test. 4
The missing room and guest selection
A response rule does not, by its existence, say which customer was selected, which room had the second guest, or whether the form was opened from a saved draft. You can arrange all of that yourself. You can also put it in an automated test.
If there are only two clicks, that is probably enough. If the state takes repeated preparation and another developer needs it too, a saved setup becomes more interesting.
Requestly can generate the rules; a test can select the rooms and guests. StatePort offers to retain a captured case. Compare the preparation and maintenance of those two setups rather than counting how many steps each tool labels automatic.
Try the same case in StatePort
Capture the failing booking flow in StatePort’s managed browser. Review the retained material and save a Card. Start the local frontend, select Local app in the Card, and choose whether to open the saved state or replay the recorded journey. 5, 6
On that path, current app code comes from your local target and matching retained backend responses come from the Card. Missing required material is a limitation to resolve, not permission for a silent call back to the original service. 6
For the example, inspect the actual second-room fields after reopening. A matching page title is not sufficient. Change the form’s error mapping, reopen again and check the same fields against the same retained rejection.
Compare one actual reopen with the existing rule-and-setup-script path. Look at the room selection and retained input, not just whether a browser window opened.
Changing the request changes the question
A frontend fix may alter the booking payload. The old rejection then stops being evidence of what the server would do with the new request.
There are two separate questions to answer. Does the UI handle the recorded error correctly? Does the live test service accept the new booking request and produce the intended result? Use retained responses for the first and an authorised integration test for the second.
If the new request no longer matches the recorded case, inspect the difference first. A deliberate response substitution is a frontend experiment; record it in the issue so it is not mistaken for a live API result.
Keep network experiments separate from saved cases
Requestly is a good fit for targeted network intervention: changing responses, testing alternatives and maintaining a set of rules that you understand. A team already combining it with stable test setup may have little reason to add StatePort.
Consider StatePort for a case that starts with a prepared interface and must survive several code edits or a handoff. Keep the HTTP tools for the response experiments they already handle.
This is not a comparison with Requestly’s API Client as a substitute for Postman. Nor does it describe importing Requestly sessions or rules directly into StatePort. Follow StatePort’s own capture path and check supported scope before choosing a real case.
For mocks maintained in source code, see the MSW record-and-replay guide.
Sources
Written by StatePort; documentation checked on 13 October 2026. Example payloads are synthetic. No comparative timings or customer results are asserted.