How to Dynamically Rewrite fetch and XHR Requests/Responses in Chrome with Receptor

If you work on frontend apps long enough, you eventually hit the same problem:

• the UI depends on backend data
• you need to test a new scenario
• you do not want to wait for backend changes
• local mocks or proxy setup feel too heavy for a quick check

For simple cases, static mocking works.

But in real apps, the response often needs to be changed dynamically. Maybe you only want to modify one field when another field has a certain value. Maybe you want to transform a request body before it is sent. Maybe you want to test conditional frontend behavior without replacing the entire payload.

That is where Receptor becomes useful.

Receptor is a Chrome extension that lets you intercept and modify fetch and XMLHttpRequest traffic directly in the browser. It supports rule-based request/response editing, and more importantly, it supports scripting for dynamic request and response manipulation.

Chrome Web Store:

Receptor on Chrome Web Store

Why Scripting Matters

Most request/response tools are limited to fixed replacements.

That works for:

• replace this response body
• add this header
• change this status code

But many real testing cases are conditional:

• if minimumAmount is "1000", set defaultAmount to "1500"
• if the request contains a certain field, inject another field
• keep most of the real response, but modify only one nested value
• simulate backend logic without changing the backend

That is exactly the gap scripting fills.

What Receptor Gives You

With Receptor, you can:

• intercept fetch and XHR traffic
• modify request headers, params, and body
• modify response headers, body, and status
• simulate delays
• organize rules with scenarios and groups
• run custom request scripts
• run custom response scripts

The scripting feature is what makes it especially flexible.

Request Script Example

Suppose your frontend sends:

{
  "plan": "basic",
  "amount": 1000
}

You want to rewrite the outgoing request before it leaves the browser.

const body = input.json || {};

if (body.plan === "basic") {
  body.amount = 1500;
}

return {
  url: input.url,
  method: input.method,
  headers: { ...input.headers },
  body: JSON.stringify(body),
};

This lets you test how the backend or frontend behaves with a different request payload without touching application code.

Response Script Example

Suppose the API returns:

{
  "minimumAmount": "1000",
  "defaultAmount": "1000"
}

You want to simulate a different backend rule.

const resBody = JSON.parse(input.body);
resBody.defaultAmount = resBody.minimumAmount === "1000" ? "1500" : "2200";

return {
  status: input.status,
  statusText: input.statusText,
  headers: { ...input.headers },
  body: JSON.stringify(resBody),
};

Now the frontend receives a modified response, even though the real server returned something else.

Important Detail: input.body vs input.json

This is the main thing to understand when writing scripts.

• input.body is the raw payload as text
• input.json is the parsed JSON object when the payload is JSON

If you are working with JSON, these two patterns are usually safest.

Use parsed JSON directly:

const data = input.json || {};

return {
  status: input.status,
  statusText: input.statusText,
  headers: { ...input.headers },
  body: JSON.stringify({
    ...data,
    featureEnabled: true,
  }),
};

Or parse the raw body yourself:

const data = JSON.parse(input.body);

data.featureEnabled = true;

return {
  status: input.status,
  statusText: input.statusText,
  headers: { ...input.headers },
  body: JSON.stringify(data),
};

If the payload is plain text instead of JSON, use input.body.

How To Use It

1. Install Receptor

Chrome Web Store:

Receptor on Chrome Web Store

2. Create a Rule

Match the request by URL and optionally by method, headers, params, or body.

3. Choose an Action

Pick either:

• Run Request Script
• Run Response Script

4. Write Your Script

Start small. Preserve most fields and change only what you need.

5. Reload the Page

Your app now runs against the modified request/response flow.

Practical Use Cases

Test Pricing Logic

Change amounts, limits, or eligibility fields in responses.

Simulate Edge Cases

Inject unexpected values, missing fields, or alternate payloads.

Validate Feature Flags

Turn flags on or off in the response without backend changes.

Reproduce Bugs

Replay a problematic payload shape directly in the browser.

Test Request Shaping

Change outgoing request bodies or headers before they hit the server.

Why This Is Useful in Frontend Development

This saves time because you do not need to:

• modify backend code
• spin up a mock server
• configure a reverse proxy
• wait for staging changes
• maintain large static mock payloads

Instead, you can test directly where your app already runs: inside the browser.

Final Thoughts

If you only need simple overrides, many tools can do that.

If you want dynamic request/response manipulation with custom logic, Receptor is much more interesting.

That scripting support is what makes it genuinely useful for frontend debugging, QA, and API testing.

Try it here:

Receptor on Chrome Web Store