Backend & API Suite

Mock API Interceptor

Intercept any frontend network request based on URL patterns and force a custom response. Build and test every UI state without touching the backend.

Overview

God-Mode Control Over the Network Layer

Building a resilient, professional UI requires testing scenarios that are nearly impossible to trigger reliably in a stable backend: a 500 server crash, a 503 service outage, an empty dataset, an extreme latency spike, or a 429 rate limit error. The Mock API Interceptor gives you total control over these scenarios.

It works by intercepting outgoing fetch() and XMLHttpRequest calls from the proxied page via a bridge script and substituting them with your configured mock responses—entirely without touching the backend or writing any code.

  • URL Pattern Matching: Match by exact path or use wildcards (e.g., /api/v1/users/* to intercept any user-specific endpoint).
  • Status Code Override: Force any HTTP status code (200, 201, 400, 401, 403, 404, 422, 429, 500, 503…).
  • Custom JSON Response Body: Write the exact JSON payload the frontend will receive.
  • Latency Injection: Add an artificial delay (in milliseconds) to simulate slow network conditions or database query timeouts — perfect for testing loading skeletons.
  • Per-Rule Enable/Disable Toggle: Each rule has an individual toggle switch. Turn rules on/off without deleting them.
  • Hit Counter: Each rule tracks how many times it has been triggered, shown as a badge on the rule card.
  • Persistent Rules: Rules are stored in localStorage and persist across browser restarts.
Workflow

Testing a 500 Error State End-to-End

  1. 1

    Open the Mock API panel

    Click the server/mock icon in the left rail.

  2. 2

    Create a new rule

    Click "Add Rule". In the pattern field, enter the endpoint path (e.g., /api/v1/checkout).

  3. 3

    Configure the mock response

    Set the Status Code to 500. In the response body, enter {"error": "Internal server error. Please try again."}.

  4. 4

    Enable the rule

    Toggle the rule to active (green left border appears on the card).

  5. 5

    Trigger the interaction in the UI

    Click "Checkout" in your previewed application. Instead of hitting the real backend, the interceptor returns your mocked 500 response instantly.

  6. 6

    Verify your UI handles it correctly

    Does your UI show an error toast? Does the button reset? Does it display the error message correctly? This is exactly what QA tests should cover.

Pro Tips
💡
Test loading skeleton UIs with latency injection Set a 3000ms latency on your data-fetching endpoints to verify your skeleton loaders, loading spinners, and transition states all work correctly. This is impossible to test reliably without a tool like this.
💡
Test empty states and pagination edge cases Return an empty array [] from a list endpoint to verify your "No results found" empty state renders correctly. Return 1000 items to stress-test your virtualization and pagination logic.
💡
Simulate a 429 Rate Limit Return a 429 Too Many Requests response with a Retry-After header to verify your frontend correctly displays a rate-limit warning and backs off its requests.