How to Mock a REST API Before the Backend Is Ready

Use POST /payments with amount in minor units and currency as the shared example. Agree on required fields and the 201 payment body before wiring a screen to a service. A mock is useful when both frontend and backend developers understand what it represents.

Prepare at least a Created variant returning 201 and a Validation failed variant returning 422. Include realistic error codes and response headers. A configured static response demonstrates a scenario; it does not prove validation, persistence or payment processing exists.

Created: 201
Content-Type: application/json
{"id":"pay_123","amount":4900,"currency":"EUR"}

Validation failed: 422
Content-Type: application/json
{"code":"invalid_amount","message":"Amount must be positive"}

Open POST /payments in API Designer. Add named variants, set the status, headers and JSON body, then enable the variants you want to call. An optional delay can help examine loading states. Saving mock configuration does not send a request.

Variant selection is explicit. To test the error state, send X-Rest-Test-Mock: Validation failed. Do not assume the runtime evaluates amount and selects that variant automatically. Keep examples synchronized with the operation's request and response schemas.

Copy the workspace mock base URL from the dashboard or Integrations and create the appropriate mock server key. Set MOCK_BASE_URL and MOCK_SERVER_KEY only in a trusted local shell or server environment. The base URL already contains /api/public/v1/mock/{workspaceId}; append /payments once.

This POSIX shell example selects the saved error variant. Expected configured result: 422 with the invalid_amount body. Hosted calls consume the account's mock quota. The key must authorize the workspace in the URL.

curl --request POST "$MOCK_BASE_URL/payments" \
  --header "Authorization: Bearer $MOCK_SERVER_KEY" \
  --header "Content-Type: application/json" \
  --header "X-Rest-Test-Mock: Validation failed" \
  --data '{"amount":0,"currency":"EUR"}'

Keep the workspace mock server key on a trusted development backend. Have that backend call the mock runtime and forward only the intended result to your frontend. Never embed the key in a browser bundle, public environment variable, URL or client log.

Switch the server-side mock origin to the real service when it is ready. Test success, validation and transport errors separately. A static mock cannot reproduce authorization decisions, concurrent updates or real backend side effects.

Browser -> development backend -> REST Test hosted mock
                                 Authorization: Bearer <server-only-key>

Frontend expectation for selected error variant:
status: 422
body.code: "invalid_amount"

For mock_not_found, check the method, path, variant name and enabled state. A workspace mismatch can return 403. Check key scope, account quota and the copied base URL before retrying. Share sanitized diagnostics rather than credentials.

Browser Runner remains subject to CORS. Cloud Runner uses backend connectivity and network protections; it cannot guarantee access to private networks. Neither execution mode makes a mock equivalent to a production payment service.