Which URL a Request Uses

A request carries its own URL. An environment carries one endpoint per service. Which of the two is used depends on the environment you have selected — and the same rule applies whether you press Send in the playground, run a test case, or start the same project from the CLI.

The rule

Selected environment	Host comes from	The URL box
Default	the URL stored on the request, the test step or the saved named request	editable, and shows that URL
any other environment	that environment's Service Endpoints value for the service the request is bound to	read-only, and shows the environment's host

Variable substitution (${name}) runs after that choice, on whichever host was picked. So a URL you typed and an endpoint stored in an environment can both contain variables, and one environment can repoint everything at once.

A request only has an environment endpoint while it is bound to a service — a step or a playground request with an operation selected. A free-form / generic HTTP request is addressed by exactly what you type, in every environment, because there is no service whose endpoint could own it. Its own ${variables} still substitute, so you can move those requests by redefining a variable instead.

Switch a project to another host

1. Import the specification and build your case under Default. The URL each step carries is the one the import read from the specification's first server entry; edit it freely while Default is selected.
2. Open Environments (the environment selector in the request editor, or the environment manager for the full list) and create Prod. The new environment already lists every service, copied from Default.
3. On the Service Endpoints tab, set the service's endpoint to https://airline-prod.example.com. Leave the request's own URL alone.
4. Select Prod in the environment selector. The URL box now shows the Prod host and is read-only.
5. Send, or run the case. The request goes to Prod.
6. Select Default again. The URL box shows the URL from step 1 — switching environments never overwrites what you typed.

Nothing needs to be re-entered per request: the environment is the only thing that changed between step 5 and step 6.

One gateway address for a whole estate

Enterprises commonly expose every service under a single address and dispatch by path — an API gateway or reverse proxy doing virtual-host routing (Envoy virtual_hosts, Istio VirtualService, NGINX server_name, Spring Cloud Gateway path predicates; the SOA-era ancestor was the ESB). Aethrix fits that shape: define the gateway once per environment and let every endpoint hang off it.

Variables per environment:

Variable	Default	Stage	Prod
GATEWAY	http://localhost:8080	https://stage-gw.corp.example	https://gw.corp.example

Service endpoints, written once and never again:

Service	Stage	Prod
Airline	${GATEWAY}/airline	${GATEWAY}/airline
Booking	${GATEWAY}/booking	${GATEWAY}/booking
Payments	${GATEWAY}/payments	${GATEWAY}/payments

Selecting Prod moves all three services, and every step bound to them, with no per-request edit. The URL box shows ${GATEWAY}/airline as you wrote it; the request leaves with the gateway substituted, which the run diagnostics report as the URL actually sent.

What the interface reports

• Read-only URL field. Outside Default the field is locked and displays the environment's host, so what you read is where the request goes.
• Restore Default URL. The button next to the field is enabled only under Default. If the URL you typed differs from the endpoint saved in Default, it names both values and asks before replacing — Enter cancels, and Keep my URL leaves your value alone. It never runs silently, because the only thing it can throw away is something you typed.
• Run diagnostics. Each send reports the URL it used. When an environment supplied the host, the step's pre-processing notes also show the stored URL and the host it was replaced with.
• CLI. aeth --env Prod selects the environment the same way the IDE does, so the host changes with it. See Command Line.

Details worth knowing

• An endpoint is the service's base address. For an imported OpenAPI or WSDL service, the operation's path is added on top at send time, so https://airline-prod.example.com is right and https://airline-prod.example.com/bookings/{ref} is not. All operations of one service share the one address.
• A saved named request keeps your URL. Saving from the playground stores what you typed, not the environment's host — reopening that request under Prod still resolves through Prod.
• Unresolved variables are not dropped. Names are matched case-sensitively. If ${PORT} has no value in the selected environment, it stays in the URL exactly as written and the send fails with the transport's own message naming the URL it tried to use; you see the mistake instead of a request silently going elsewhere.
• A missing endpoint row falls back to the imported address. If an environment has no value for the service, the address the specification was imported with is used. Creating an environment copies the rows from Default, so this only comes up after a service was added to Default and not filled in.
• Cleaning up. Clean Up Unused Services on the environment manager removes endpoint rows no step or request references any more.
• A free-form request is the exception, and so is a template that is not bound. Security-test instances keep the operation binding of the step they were generated from, so a scan follows the environment exactly like the request it came from; a template bound to nothing produces generic instances, which are addressed by the URL they carry. Contract-verification steps are bound when the contract recorded an operation id, and replay the URL written into the contract otherwise — so a contract exported from a bound step also moves with the environment.
• An explicit target beats the environment nowhere else but here. aeth verify-contract --url, and the verify dialog's URL field, set the address deliberately; while a non-Default environment is active that environment's endpoint for the bound operation still wins, and the run's report shows the host it actually used. Run the verification under Default when the point is to probe one specific address.

See Also

• Environments & Variables — credentials, scoping and the variable syntax
• Global environments — the same rule for the playground's global scope
• Data-Driven Testing — feeding ${variables} from a data source