Then it behaves.
Cookies are scoped to a subdomain of your own domain, so the browser treats the proxy as your own infrastructure. Requests are same-site. Secure and SameSite=Strict stop being obstacles.
Custom domains
If your app logs in with cookies, put FlowMock on your own domain.
A CNAME to a subdomain you already own. Cookies behave like same-site, login keeps working, and the proxy URL stops looking like someone else's infrastructure.
“Login works on staging. Through the proxy it just bounces back to the login screen.”
That's not a bug you need to debug. That's cookies doing exactly what cookies do.
Why it happens — say it plainly, then fix it
Your app authenticates by cookie. Cookies are scoped to a domain, and modern browsers enforce SameSite and Secure. When your frontend talks to p.flowmock.dev instead of staging-api.yourcompany.com, the browser sees a different site — so it withholds the session cookie, and Set-Cookie responses get dropped. Nothing is broken; the rules are just being followed.
The fix is to stop being a different site.
The setup — four steps, one afternoon at most
- 1
Add a domain in FlowMock — qa-api.yourcompany.com, or whatever fits your DNS conventions.
- 2
Create a CNAME pointing at FlowMock's target.
- 3
Verify it. One proof covers the registrable domain and its subdomains.
- 4
Point your app at https://qa-api.yourcompany.com instead of the default proxy URL.
Frontend and API on different subdomains? Handled.
If your API lives on qa-api.yourcompany.com and your frontend on the apex or another subdomain, FlowMock rewrites Set-Cookie to your registrable root — Domain=yourcompany.com — so the session is shared across subdomains the way it was before you added a proxy.
What gets forwarded
Request cookies, Set-Cookie responses, Authorizationand custom token headers — all passed through untouched, unless you've configured a redaction rule. FlowMock doesn't strip or rewrite auth. That's the point.
One domain, as many environments as you need.
Environments (we also call them proxy slots) are deployments of the same project. They share one mock library and one set of scenarios, but each gets its own proxy URL and its own traffic. Give staging one, give each parallel QA lane its own, give the mobile team theirs. The scenario a tester saves on one environment is available on all of them, because the library is the project's, not the URL's.
Not on cookies?
Then you don't need any of this. Point your app at the default p.flowmock.devURL and you're done — the custom domain is worth it later for the branded URL, not for correctness. Also worth knowing: FlowMock can identify testers from the JWT you're already sending, so there may be nothing to change in your app at all. See QA Sessions.
Step-by-step DNS help also lives in the cookie auth docs.
One URL change. That's the whole integration.
Free plan, no card, two-minute setup.