Skip to main content
If your frontend team is blocked waiting on a backend that isn’t ready yet, GetRequest lets you stand up a realistic mock instantly. Create a JSON endpoint, define the response your frontend expects, and start making real HTTP calls — all without writing a single line of server code. When your backend ships, flip the endpoint to Forward and traffic routes there automatically, with zero downtime and no frontend changes required.

Create a JSON endpoint

1

Open your project

Navigate to your project in the GetRequest dashboard and click New Endpoint.
2

Set the action to JSON

In the Action field, select JSON. This tells GetRequest to serve a static response body instead of proxying to an upstream URL.
3

Define your response body

Enter the JSON your frontend expects. For example, a user profile endpoint:
4

Click Create

Your endpoint is live immediately at:
Your frontend can start calling it right now. Responses are returned in milliseconds with status 200.

Match the real API shape

The more closely your mock mirrors what the real backend will return, the fewer breaking changes you’ll encounter when you switch. Always mock the full response envelope — including pagination wrappers, metadata fields, and nested objects — not just the core data. For a paginated list endpoint, include the envelope your frontend will need to parse:
Review your API contract or OpenAPI spec before writing mock data. Consistent field names and types now mean zero frontend refactors later.

Switch to your real backend — zero downtime

When your backend is ready, you don’t need to touch your frontend config or redeploy anything. Edit the endpoint directly in GetRequest:
1

Open the endpoint editor

Find the endpoint in your project and click Edit.
2

Change the action to Forward

Switch Action from JSON to Forward.
3

Set your destination URL

Enter the URL of your real backend handler, for example:
4

Save

All future requests are proxied to your backend immediately. GetRequest forwards the original request headers and body verbatim — your backend receives the exact same request the caller sent.
The switch is instantaneous. There is no deployment, no DNS propagation, and no downtime. Requests in-flight before you save are served the old JSON response; requests after are forwarded to your backend.

Useful patterns

Different responses per environment

Create two endpoints with the same slug in separate projects — one project per environment (dev, staging). Point your frontend environment variables at the corresponding project URI. Each environment gets its own isolated mock with no shared state.

Error state mocking

Stub out error payloads so your frontend error-handling logic runs against real error shapes before your backend ships. Model your validation error response exactly as your backend will return it.

Mocking error payloads

To simulate a validation error, set the JSON body to match your backend’s error schema:
Your frontend’s error-handling code runs against real data shapes from day one, so there are no surprises when you connect to the actual backend.
JSON endpoints always return HTTP 200 regardless of the body you define. If you need to test non-200 status codes (for example, 422 Unprocessable Entity or 503 Service Unavailable), switch to a Forward endpoint pointed at a local server or a passthrough service like httpstat.us.

Every mock request is logged

All requests to JSON endpoints are captured in Logs — the same log view used for forward endpoints. Your frontend team can verify exactly what they sent, and your backend team can inspect the shape of real traffic before their code ships. Click any log entry to see the full request headers, body, and response.