# Mocks in the Frontend Workflow — Routebase > Starting on day one instead of waiting, the base URL as configuration rather than a code branch, CORS and tokens in a browser, and what changes on the day you switch to the real backend. Canonical page: https://routebase.dev/guides/api-mocking/mocking-for-frontend-development/ Chapter 8 of 10 · API Mocking · Last reviewed 2026-09-13 · The Routebase Team The strongest argument for a mock is a calendar one. A contract agreed on Monday can have a callable implementation of itself by Monday afternoon, which means the client work starts weeks before the provider does. Getting that benefit without paying for it later comes down to a few decisions about how the client reaches the mock. ## The base URL is configuration, never a branch The single most expensive mistake is a conditional in application code that chooses between the mock and the real API. It looks harmless. It creates a code path that only exists in development, so the path that will run in production is the less tested of the two. It also spreads, because the second conditional is always easier to add than the first one was, and eventually the mock-only branch is doing something the real branch does not. The rule is that nothing above the transport layer knows which server is answering. One base URL, supplied by configuration, changed by an environment variable. The client is then identical in both cases and switching is a deployment concern rather than a code change. ## What a browser needs that a test runner does not Calling a mock from a terminal is trivial. Calling it from a page is where two extra things appear. **Cross-origin access.** Your development server and the mock are different origins, so the browser will not read the response unless the mock allows the origin explicitly. This is worth setting up on the first day rather than debugging on it, because the failure arrives as a policy message and reads like a problem with the request. **A credential, sometimes.** A mock on a public URL is reachable by anyone with the address. The data is invented, so that is usually fine, and where it is not, a token required on every request closes the door without changing how the client calls it. The important part is that the token is supplied the same way the real credential will be, so the code that attaches it is the code that ships. ## Where the mock lives matters more than it looks A mock that runs on one developer's machine and a mock that lives at a shared address are two different tools. A local mock is private, fast and invisible to everyone else. It cannot be opened by a designer, attached to a preview deployment or called from a pipeline, and each teammate has their own slightly different copy of it. A hosted mock has one address that everybody, including automation, can reach. Everyone sees the same behaviour, a preview build can point at it, and a pipeline can run against it without provisioning anything. The trade is that its state and configuration are shared. One person turning on a failure probability is doing it for everybody. ## Using the log as the debugger A frontend integrating against anything spends most of its debugging time on one question, which is whether the request that was sent is the request that was meant. A mock is in an unusually good position to answer that, because it can record exactly what arrived. A request log showing the method, the path, the query string, the headers and the body turns a guess about a serialisation bug into a fact in about ten seconds. It also settles the most common confusion. That is a `404` where the path was subtly wrong rather than the rule missing. ## The day you switch If the mock was doing its job, switching is uneventful. What remains is worth naming so it is not a surprise. Authentication is the big one, because the mock accepted whatever it was given and the real service will not. Expect to spend the switch day on tokens, refresh behaviour and redirects rather than on rendering. After that come the things a comfortable mock hid, which are latency, failures and limits. Those should have been configured long before, which is what [making the mock unpleasant](/guides/api-mocking/simulating-errors-latency-and-rate-limits/) is about. A team that did it meets a short list of genuine surprises, and a team that did not meets every missing state in the same week. ## In Routebase The mock server has a stable public base URL per project, so the same address works from a laptop, a preview deployment and a pipeline without anyone provisioning anything. The [API-first development](/api-first-development/) page shows where that URL sits in the workflow, next to the tests and monitors that wait for the backend the same way. _Screenshot: Every request the mock handled is listed with its status and timing, and the entries that no rule matched are visible as 404s next to the ones that were answered, which is usually the fastest way to tell a wrong path from a missing rule._ **CORS** is switched on per server with an explicit list of allowed origins, so your development host and your preview domain can call it from a browser. **Require Access Token** adds a token that callers send as a bearer header or as a query parameter. Regenerating it at any time revokes the previous one immediately. Expanding a log entry shows whether the response came from a rule or was proxied, which rule matched, and the full request and response headers and bodies, each copyable. The log filters by method, path, status class and source. It narrows to a single rule while that rule is selected. The API designer's **Try It** panel can target the mock directly, so a request can be checked against the mock and against a real environment from the same screen. [Mock Server Settings](https://docs.routebase.dev/mock-server-settings/) covers CORS and tokens, and the [Mock Server](https://docs.routebase.dev/mock-server/) guide covers the log. ## Frequently asked questions ### How do you use a mock API for frontend development? Point the client at the mock through the same configuration that will later point it at staging, then build against it as though it were real. The rule that makes this work is that no application code knows which one it is talking to. A conditional around the base URL becomes a second code path that only the mock ever exercises. ### Why does a mock server need CORS? Because a browser refuses a cross-origin request unless the server that answers it says otherwise, and a mock on its own domain is cross-origin to your development server. Without the right origin allowed, the request fails before the response is read, and the console message is about the policy rather than about the API. Every browser-facing mock needs the origins your app runs on listed. ### Should a mock server be public? A mock on a public URL is the easiest thing to share with a teammate, a preview deployment or a pipeline, and it is also readable by anyone who guesses the address. Since a mock carries invented data rather than customer data, that is usually acceptable, and where it is not, requiring a token on every request closes it without changing how anyone calls it. ### What breaks when you switch from a mock to the real API? Authentication, latency and the error cases, roughly in that order. The mock accepted whatever credential it was handed and answered instantly, while the real service refuses, redirects and takes its time. Everything else is usually small, which is precisely why the mock should have been slow, occasionally broken and rate limited well before that day. --- [Routebase](https://routebase.dev/) — [Sign up](https://app.routebase.dev/): Every account starts with a 14-day Pro trial — no credit card required.