Skip to main content
When a routing rule is set to Proxy, GoDizzy forwards the request to your collection’s target endpoint and streams the response back. By default the response is passed through unchanged. Proxy response shaping lets you intercept that response and modify it — changing the status code, injecting or removing headers, or transforming the body — before the caller receives it. This is useful for injecting error codes that the upstream never returns in staging, normalizing inconsistent API shapes across environments, or testing how your agent handles missing or malformed fields from a live upstream.

​
How shaping works

Shaping is an optional configuration attached to a proxy rule. When GoDizzy receives the upstream response it applies your shaping config in this order:
  1. Override the status code (if configured)
  2. Set or remove response headers
  3. Transform the body
The shaped response is then returned to your agent or client.
Shaping configs are versioned the same way mock responses are — every save creates a new version, and you can view history and revert to any prior version.

​
Override the status code

Enter a replacement HTTP status code in the Status code override field. GoDizzy discards the upstream status and returns yours instead. Leave the field empty to pass the upstream status through unchanged. Example use case: Your staging upstream always returns 200 for payment endpoints because the test environment never fails. Override to 402 to test how your agent handles a payment-required response without changing the upstream.

​
Set and remove headers

In the Headers section of your shaping config, you can add header operations:
  • Set — Adds the header to the response (or replaces it if the upstream already sent it). Provide a set object mapping header names to values.
  • Remove — Strips the named header from the upstream response before returning it. Provide a remove array of header names.
You can combine both in the same config: 
{
  "set": {
    "X-Upstream-Region": "us-east-1",
    "Cache-Control": "no-store"
  },
  "remove": [
    "X-Internal-Trace-Id",
    "X-Debug-Info"
  ]
}
Template variables (including {{$reqBody['key']}} and {{$resBody['key']}}) work in header values — see Template variables below.

​
Transform the body

The default. GoDizzy returns the upstream body exactly as received. Select this mode when you only need to modify the status code or headers.
{
  "mode": "unchanged"
}

​
Template variables

Proxy response shaping supports the same template variables as mock responses, plus one additional context: the upstream response body.
SyntaxAvailable inDescription
{{$randomUUID}}Body, headersNew UUID per response
{{$isoTimestamp}}Body, headersUTC timestamp at response time
{{$unixSeconds}}Body, headersUnix epoch seconds
{{$unixMs}}Body, headersUnix epoch milliseconds
{{$date}}Body, headersYYYY-MM-DD in UTC
{{$randomInt(a,b)}}Body, headersRandom integer in range
{{$randomAlphaNumeric(n)}}Body, headersRandom alphanumeric string
{{$randomBoolean}}Body, headerstrue or false
{{$randomHex(n)}}Body, headersRandom hex string
{{$reqBody['key']}}Body onlyTop-level field from the incoming request JSON body
{{$resBody['key']}}Body onlyTop-level field from the upstream response JSON body
{{$reqBody['key']}} is only available when the rule’s method is POST, PUT, or PATCH. {{$resBody['key']}} is only available in Full replace and JSON field patch body transforms — not in headers.

​
Version history and rollback

Every time you save a proxy shaping config, GoDizzy stores a new immutable version — identical to how mock response versioning works.
1

Open version history

On the rule detail page, click View History on the proxy shaping section. You will see a list of every saved config with the timestamp and the email of the team member who saved it.
2

Inspect a version

Click any version to see the full config: status override, header operations, and body transform mode and payload.
3

Revert

Click Revert to this version. GoDizzy creates a new version with the content of the selected config. Your full history is preserved.

​
Example: normalize an inconsistent upstream

Your staging upstream returns a user object, but your production upstream wraps it in a data envelope. Use a full replace shaping config on the staging proxy rule to make staging return the same shape as production: 
{
  "mode": "replace",
  "content": "{\"data\": {\"id\": {{$resBody['id']}}, \"email\": {{$resBody['email']}}, \"plan\": {{$resBody['plan']}}, \"created_at\": \"{{$isoTimestamp}}\"}}"
}
Your agent always sees data.id, data.email, and data.plan — regardless of which environment is serving the request.