> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getrequest.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Mock APIs Instantly with GetRequest JSON Endpoints

> Stand up a realistic API mock in under 60 seconds — no server, no code, no Docker. Unblock your frontend before your backend exists.

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

<Steps>
  <Step title="Open your project">
    Navigate to your project in the GetRequest dashboard and click **New Endpoint**.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Define your response body">
    Enter the JSON your frontend expects. For example, a user profile endpoint:

    ```json theme={null}
    {
      "id": "usr_01HXYZ",
      "email": "alice@example.com",
      "plan": "pro",
      "created_at": "2024-01-15T09:00:00Z"
    }
    ```
  </Step>

  <Step title="Click Create">
    Your endpoint is live immediately at:

    ```text theme={null}
    https://e.getrequest.io/{project_uri}/{slug}
    ```

    Your frontend can start calling it right now. Responses are returned in milliseconds with status `200`.
  </Step>
</Steps>

## 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:

```json theme={null}
{
  "data": [
    { "id": "req_001", "method": "POST", "status": 200 },
    { "id": "req_002", "method": "GET",  "status": 404 }
  ],
  "meta": {
    "next_cursor": "req_002",
    "has_more": true
  }
}
```

<Tip>
  Review your API contract or OpenAPI spec before writing mock data. Consistent field names and types now mean zero frontend refactors later.
</Tip>

## 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:

<Steps>
  <Step title="Open the endpoint editor">
    Find the endpoint in your project and click **Edit**.
  </Step>

  <Step title="Change the action to Forward">
    Switch **Action** from `JSON` to `Forward`.
  </Step>

  <Step title="Set your destination URL">
    Enter the URL of your real backend handler, for example:

    ```text theme={null}
    https://api.yourapp.com/v1/users/me
    ```
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Note>
  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.
</Note>

## Useful patterns

<CardGroup cols={2}>
  <Card title="Different responses per environment" icon="layer-group" href="#useful-patterns">
    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.
  </Card>

  <Card title="Error state mocking" icon="triangle-exclamation" href="#mocking-error-payloads">
    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.
  </Card>
</CardGroup>

### Mocking error payloads

To simulate a validation error, set the JSON body to match your backend's error schema:

```json theme={null}
{
  "message": "The email field is required.",
  "errors": {
    "email": ["The email field is required."]
  }
}
```

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.

<Warning>
  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](https://httpstat.us).
</Warning>

## 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.