Relay365Multi-model API relay desk
← All desk bulletins
Wire & endpointsEN1 desk reads

Shift Note: Bare Hosts and Doubled /v1 Paths

The deployment looked healthy until the first model request returned a 404. Authentication was configured, the hostname resolved, and the SDK initialized without complaint. The failure was in the address assembled after initialization: a missing version prefix, a duplicated path, or a proxy rewrite nobody had checked.

This shift note compares the configuration choices that commonly cause those failures. The deciding evidence is the final outbound URL, not whether a value looks reasonable in an environment file.

Bare host against the SDK-ready base

A service address and an SDK base URL are not necessarily interchangeable. Relay365 publishes its API base as https://api.api365relay.com. OpenAI clients add /v1, so their configured base should be https://api.api365relay.com/v1.

For a chat completions request, an OpenAI SDK typically appends the resource path chat/completions to its configured base. With the correct configuration, the resulting path is /v1/chat/completions. Supplying only the hostname can instead produce /chat/completions, which may not match the service route.

The bare host is not universally wrong. Another client or adapter might add the version prefix itself. Copying an OpenAI SDK configuration into that adapter without checking its behavior can introduce the opposite problem.

Verdict: For Relay365 with an OpenAI SDK, configure the base with /v1. For other clients, follow their provider-specific configuration instructions rather than assuming identical path handling.

Base directory against a complete resource endpoint

A complete endpoint looks more precise than a base directory, but precision in the wrong field breaks composition. Setting an SDK base to https://api.api365relay.com/v1/chat/completions can cause the client to append its own resource path again.

The same mistake appears when teams append /v1 in both application configuration and a shared client factory. Each layer looks correct in isolation; together they send requests toward /v1/v1/chat/completions.

Model selection belongs elsewhere. For example, choosing Gemini 2.5 Flash does not mean adding that model name to an OpenAI-compatible base URL. Use the model identifier accepted by the service in the request's model field.

Verdict: Give the SDK a base directory, not a completed operation URL. Assign ownership of the version prefix to one layer and document that choice.

Implicit URL joining against an observed request

Trailing slashes attract attention because URL resolution can treat a base ending in /v1 differently from one ending in /v1/. A leading slash in a resource path can also replace an existing path prefix under standard URL resolution rules.

However, SDKs do not all use raw URL resolution unchanged. Some normalize base paths or implement their own joining logic. A slash rule learned from one HTTP library is not reliable evidence about another SDK.

Verdict: Prefer the documented base format, then inspect a request produced by the actual SDK version you deploy. Do not approve a configuration solely because a manually assembled request succeeds.

Direct routing against reverse-proxy rewriting

A direct request can work while the same SDK fails behind a gateway. The proxy might strip /v1, preserve an internal prefix, or add another version segment. The application-side URL alone cannot establish what reaches the upstream service.

  • Record the outbound hostname and path without logging authorization headers or sensitive request bodies.
  • Compare the application's request path with the upstream path recorded by the proxy.
  • Check that the running process received the intended base URL rather than a stale environment value.
  • Confirm the requested API operation is supported before treating every 404 as a path-joining defect.

Verdict: Direct routing is the simpler diagnostic baseline. Keep a proxy when it serves an operational need, but make its path transformation explicit and testable.

One relay address still needs client-specific configuration

Relay365 fits teams that want pay-as-you-go access across multiple model families through one relay desk. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDKs, but shared service access does not make every client's configuration fields interchangeable.

If that operating model fits your workload, create a Relay365 account and validate one small request before distributing the configuration.

Final verdict: For OpenAI SDKs, start with https://api.api365relay.com/v1, keep operation paths out of the base, and verify the emitted URL. For other clients, establish their path contract separately. A reusable configuration is one whose final route has been checked, not merely copied.

Further desk bulletins

Curious how it runs on your own code? Sign up →