1. Understand what an OpenAI-compatible endpoint accepts
An OpenAI-compatible endpoint lets your application communicate with a model service using familiar OpenAI-style requests. Instead of learning a separate request format for every provider, you can often keep the same SDK and change a few settings.
Think of compatibility as a shared interface, not a promise that every feature behaves identically. Basic text conversations may transfer easily, while tool calling, structured output, images, and streaming can require model-specific checks. Start with a simple text request before adding those features.
2. Separate the host, base URL, and request route
These three terms describe different parts of the destination. Mixing them up is a common reason a first request fails.
- Host: the service address, such as https://api.fastapirelay.com.
- Base URL: the prefix your SDK uses for API requests. For an OpenAI SDK with SwiftRelay, use https://api.fastapirelay.com/v1.
- Request route: the operation added to that prefix, such as /chat/completions.
Together, that base URL and route produce https://api.fastapirelay.com/v1/chat/completions. An SDK normally adds the route itself. Do not put the complete chat completions address into its base URL setting.
3. Prepare a key and an exact model identifier
SwiftRelay is a practical option when you want one relay for models from multiple providers with an OpenAI-compatible SDK. Sign up for SwiftRelay, collect the small gift credit available to new accounts, and create an API key.
Keep that key in an environment variable or a secrets manager. Never embed it in browser code, commit it to a repository, or paste it into a public troubleshooting thread.
Next, choose an available model, such as Gemini 2.5 Flash, and copy its exact API identifier from the service’s model listing. A readable model name is not necessarily the identifier accepted in a request. Do not invent an identifier by lowercasing the display name.
4. Send one small chat completions request
A minimal request needs authentication, a model identifier, and a message. With curl installed, the following command shows the complete request shape. Replace YOUR_API_KEY and MODEL_ID locally before running it:
curl https://api.fastapirelay.com/v1/chat/completions -H "Authorization: Bearer YOUR_API_KEY" -H "Content-Type: application/json" -d '{"model":"MODEL_ID","messages":[{"role":"user","content":"Explain an API endpoint in one sentence."}]}'
The Authorization header identifies your account. The model field selects the model, and messages contains the conversation. Here, user marks your prompt as something the model should answer. For a standard chat completions response, look for the assistant’s text in choices[0].message.content.
5. Move the working settings into your SDK
Once the basic request works, configure your OpenAI SDK with the same API key and the base URL https://api.fastapirelay.com/v1. Pass the same model identifier and messages to its chat completions method. Exact constructor names vary by language and SDK version.
Do not assume that every SDK operation is supported just because chat completions works. If your application uses another API route, check that route separately. Likewise, Claude Code and Gemini CLI use the bare SwiftRelay host, https://api.fastapirelay.com, rather than the OpenAI SDK base URL.
6. Diagnose failures before changing the prompt
- Authentication failure: check the key, its permissions, and whether your application actually loaded it.
- Route not found: check for a missing /v1, a duplicated /v1, or an unsupported operation.
- Model error: verify the exact identifier and current availability.
- Unsupported parameter: remove optional settings and retry the minimal request.
Read the returned error message before changing multiple settings. Keep keys and private prompts out of diagnostic logs.
7. Check token usage before expanding the conversation
SwiftRelay bills per token on a pay-as-you-go basis. Both the prompt you send and the answer you receive can contribute to cost, with rates depending on the selected model. Review current pricing and inspect returned usage information when available.
Keep the first test short. Once authentication, routing, model selection, and response parsing work, add conversation history and advanced features one at a time. That gives you a clear baseline whenever something breaks.