Best Practices
None of the rules below are enforced by Tigrister — they are conventions that keep a mock server readable, reliable, and easy to come back to after a few weeks away from it.
One Server per API Surface
Keep each mock server focused on a single real API. A server called Payment API holds the payment endpoints, a server called Auth holds the login and session endpoints, and so on. Mixing unrelated endpoints into one big server makes the endpoint tab strip long and hard to read, and defeats the purpose of the port number — which ideally matches the real service's port so your client does not need environment-specific URLs.
Keep the Default Variant Boring
The default response variant is what your client falls back to when no rules match. Keep it as the happy path — the shape your client sees 95% of the time — and put edge cases, errors, and variations into non-default variants guarded by rules. This way, a partially-written set of rules still produces working behaviour: you fall back to "everything is fine" rather than to an error.
Fix Duplicate Endpoints Immediately
As soon as you see the small triangle warning icon on an endpoint tab, stop what you are doing and fix it. A duplicate endpoint will not be saved while the conflict exists, which means your edits are silently discarded on save — and it is easy to assume the mock is responding the way you typed it when it is actually answering from the first (original) endpoint. Rename the path, change the method, or delete one of the two to clear the warning.
Leave the Port Blank When You Can
If the client does not care what port it talks to, leave the port field empty when you create the server. Tigrister auto-assigns a free port starting from 4000, which avoids collisions with other mock servers, avoids the reserved ports, and avoids ports that a different application on your machine might already be using. Pick a specific port only when there is a concrete reason to.
Use Random Variables for Anything Identifier-Shaped
Hard-coding the same UUID or the same integer ID in every response variant eventually bites you — caching layers, unique constraints, and client-side de-duplication can all misbehave in subtle ways when they see the same value twice. Use random variable tokens inside response bodies for anything that represents an identifier, a timestamp, or a generated field. The Preview button lets you double-check the rendered shape before starting the server.
Use Rules, Not Separate Endpoints, for Variations of the Same Route
If the same METHOD /pathshould return different responses depending on the incoming payload or a header, resist the urge to create two endpoints with the same method and path — you will hit the duplicate warning and nothing will save. Instead, create one endpoint with multiple response variants and let the Rules tab decide which variant is served. The default variant handles everything the rules do not catch.
Edit Freely While Running
You do not need to stop the server to tweak a response body, change a status code, or add a new rule. Saved changes take effect on the next incoming request. The only moment you need to stop the server is when the port itself has to change, or when you want it to no longer be answering at all.