General Client Configuration

If a client supports Anthropic Messages, OpenAI Responses, or OpenAI Chat Completions, you can use this guide to connect it to SoleAPI. Setting names vary between clients, but the essential steps are to select the correct protocol and send requests to its corresponding endpoint. SoleAPI currently has fewer upstream sources for OpenAI Chat Completions; OpenAI (GPT) and xAI (Grok) are confirmed to work.

Before you begin, create an API Key, make sure it includes the group containing your target model, and copy the model ID from the Model Catalog.

Identify the client field type first

In the client's custom model, provider, or connection settings, find the protocol type, Base URL (or API Endpoint), API Key, and model ID. Some clients expect a base address, while others expect the complete request URL. Determine which one the field requires before entering a value.

Option 1: Anthropic Messages

Select Anthropic, Anthropic Messages, or an equivalent protocol option in the client:

• If the client appends /v1/messages, enter https://soleapi.com.
• If the client appends /messages, enter https://soleapi.com/v1.
• If it expects a complete request URL, enter https://soleapi.com/v1/messages.
• API Key: enter the Key created in the SoleAPI console.
• Model ID: enter the model ID shown in the Model Catalog.
• Authentication: if selectable, use the Anthropic API Key or x-api-key option.

The client normally sends headers such as x-api-key and anthropic-version automatically. Enter only the Key itself in the API Key field; do not add a Bearer prefix manually.

This configuration uses SoleAPI's POST /v1/messages endpoint. See Messages API for fields and request examples.

Option 2: OpenAI Responses

Select OpenAI Responses, Responses API, or an equivalent protocol option in the client:

• If the client appends /responses, enter https://soleapi.com/v1.
• If it expects a complete request URL, enter https://soleapi.com/v1/responses.
• API Key: enter the Key created in the SoleAPI console.
• Model ID: enter the model ID shown in the Model Catalog.
• Authentication: if selectable, use OpenAI Bearer Token or an equivalent option.

The client should send the Authorization: Bearer <API Key> header automatically. Normally, enter only the Key itself in the API Key field; follow the client's field instructions where they differ.

This configuration uses SoleAPI's POST /v1/responses endpoint. See Responses API for fields and response examples.

Option 3: OpenAI Chat Completions

Select OpenAI Chat Completions, OpenAI Compatible, or an equivalent protocol option. Some clients label it simply OpenAI; verify that it actually uses Chat Completions rather than Responses:

• If the client appends /chat/completions, enter https://soleapi.com/v1.
• If the client appends /v1/chat/completions, enter https://soleapi.com.
• If it expects a complete request URL, enter https://soleapi.com/v1/chat/completions.
• API Key: enter the Key created in the SoleAPI console.
• Model ID: enter the model ID shown in the Model Catalog.
• Authentication: select OpenAI Bearer Token or an equivalent option so the client sends Authorization: Bearer <API Key> automatically.

This configuration uses SoleAPI's POST /v1/chat/completions endpoint. SoleAPI currently has confirmed upstream sources for OpenAI (GPT) and xAI (Grok). Many Chinese models also support this protocol themselves, but SoleAPI has not yet added the corresponding upstream sources.

Choose a protocol by provider

Different providers currently have different protocol endpoints available on SoleAPI. See the provider and protocol table in API Compatibility Protocols, then select the client protocol that matches an available endpoint for the target model.

That table is the authoritative description of provider-to-protocol availability and is not duplicated here. When configuring a client, also use the model ID from the Model Catalog and verify the models available to the current API Key.

Special checks for OpenCode

OpenCode's built-in Anthropic provider treats baseURL as the /v1 prefix and then appends /messages. Therefore, use the following value with OpenCode's native Anthropic configuration:

{
  "provider": {
    "anthropic": {
      "options": {
        "baseURL": "https://soleapi.com/v1"
      }
    }
  }
}

Do not identify the protocol solely from labels such as “OpenAI” or “Compatible” in the settings interface. If OpenCode uses @ai-sdk/openai-compatible, requests normally go to /v1/chat/completions; that is not Anthropic Messages. To call /v1/messages, use OpenCode's Anthropic provider or another provider that explicitly uses Anthropic Messages.

The actual request path quickly identifies the protocol:

• /v1/messages: Anthropic Messages; next inspect tools and extension fields in the request body.
• /v1/responses: OpenAI Responses; next confirm that the client is using a Responses provider.
• /v1/chat/completions: OpenAI Chat Completions; SoleAPI currently has confirmed GPT and Grok upstream sources for this endpoint, but has not yet added the corresponding Chinese-model sources.
• /messages: the Base URL usually lacks /v1; add it according to the client's path-appending rules.

Current OpenAI Chat Completions scope on SoleAPI

POST /v1/chat/completions is retained as a legacy compatibility endpoint and should not be the first choice for new integrations. OpenAI (GPT) and xAI (Grok) can currently use it. Many Chinese models also support Chat Completions themselves, but SoleAPI has not yet added their corresponding upstream sources, so no endpoint is currently available for them through this protocol.

This does not mean that Chinese models lack Chat Completions support or cannot be used. Check the Model Catalog and the models available to the API Key, then select a protocol currently available on SoleAPI. Chinese models can currently use an available Messages or Responses endpoint instead.

Test and save

Save the configuration and begin with a simple text-only request. After the basic request succeeds, test tools, streaming, images, reasoning, and other features separately.

Troubleshoot in this order:

1. Confirm that the model ID is correct and belongs to a group available to the current API Key.
2. Match the protocol to the path: Messages uses /v1/messages, Responses uses /v1/responses, and Chat Completions uses /v1/chat/completions.
3. Confirm that a Base URL was not confused with a complete request URL.
4. Test a known working model before switching to the target model.
5. After basic text succeeds, test advanced features such as tool calls separately.

Why can the same protocol behave differently across clients?

“Supports Anthropic Messages” only means that a client can produce a Messages-shaped request. Clients may still differ in the following ways:

• They append paths differently, sending requests to endpoints such as /messages, /v1/messages, or /v1/chat/completions.
• They send different authentication, anthropic-version, or anthropic-beta headers.
• Coding agents automatically attach tool definitions, tool_choice, system prompts, and longer context to each request.
• Some clients enable prompt caching, reasoning parameters, image content, or specific streaming events.
• Clients impose different parsing requirements for tool calls, streaming events, and error responses.

A successful basic conversation in one client proves only that the model can handle that particular request. It does not guarantee compatibility with another client's complete agent workflow. For example, if GLM returns text through Anthropic Messages in one client but fails in another coding client, first check whether the latter adds tools or other extension fields before treating it as a model-endpoint issue.

Troubleshooting

• 404 or endpoint not found: match the protocol to the path. Messages uses /v1/messages, Responses uses /v1/responses, and Chat Completions uses /v1/chat/completions.
• The path contains /v1/v1/messages, /v1/v1/responses, duplicated /v1, or a duplicated protocol path: the Base URL already includes a version path or the client appends one automatically. Use the base address that matches the client's actual path behavior.
• 401: check that the API Key is complete, active, and unexpired, and that the authentication method matches the protocol.
• 403: check that the API Key includes the target model group. If an IP allowlist is enabled, make sure the current device IP is included.
• Text works but tool calls fail: the base protocol is usually working, but the model or upstream endpoint may not accept the tool parameters sent by the client. Disable tools or compare with a model known to support tool calls.
• One client works but another fails: compare the actual request paths, headers, and bodies. Focus on tool definitions, tool_choice, reasoning and caching fields, and streaming events rather than comparing only the protocol labels shown in settings.
• Model not found or no available endpoint: verify the model ID against the Model Catalog and confirm that it is available to the current API Key. If Chat Completions fails for a Chinese model, first recognize that SoleAPI has not yet added the corresponding upstream source rather than concluding that the model itself lacks protocol support; use an available Messages or Responses endpoint instead.