Connect a request to the right service

3 minute read · API Client

Keep one request useful across environments without sending it to the wrong service. Name the environment clearly and check it before every consequential request.

• Reuse a base URL without sharing a secret
• Choose authorization at the right level
• Diagnose a wrong environment or rejected account
• Walk one request through two environments

Reuse a base URL without sharing a secret#

Add a cluster variable such as base_url and create local/staging environments as needed. Use {{base_url}}/api/articles in a saved request. Select the intended environment before sending and inspect the resolved destination. Local-only values remain distinct from values explicitly chosen for cloud sync; imports default variables to local-only.

Keep bearer tokens, cookies and private environment values local unless sharing them is intentional and supported by the selected visibility/access boundary. A public collection does not need the author's live credentials to explain its requests.

Choose authorization at the right level#

A request can use no auth, bearer, basic or OAuth2 configuration and can inherit authorization from the cluster. Inspect inherited values when a request works in one cluster but fails after copying it. An Authorization header typed manually can conflict with a configured auth method; check the final request rather than assuming only one source exists.

OAuth operations contact the actual target service and use its own application/account rules. Cookie management likewise affects requests to the target. Vortex storing a configuration does not validate that an external provider has granted the requested access.

Diagnose a wrong environment or rejected account#

For a 401/403, confirm the destination, chosen environment, auth inheritance and token validity without publishing the token. For a placeholder that does not resolve, inspect the variable name and scope. For unexpected data, check whether the request used local, staging or production before changing anything.

Setting a variable from a selected JSON response path is useful for a multi-step workflow, but the resulting value may be a secret. Review its persistence and sharing choice. Export only the collection content you intend to share and inspect the output. Continue with collection import/export.

Walk one request through two environments#

Keep {{base_url}}/api/articles as the saved URL. In the local environment, set base_url to your local app; in staging, use the staging service. Switch environments and inspect the resolved URL before sending a read. A matching request name does not guarantee that the active environment is the same as yesterday.

Set a public default at collection level and override only what differs at request or environment level. Check inherited authentication after duplicating a request. For a login flow, inspect returned cookies or capture a chosen response field into an appropriate local variable; never export a live session along with a demonstration collection.

If an OAuth flow fails, check the target service's application settings and redirect/grant requirements. A Vortex account login is unrelated to authorization for your own API. See collection sharing before choosing which variables leave this device.

Related guides: your first request, safe collection sharing.