Alpha Search API
/v1/alpha/search is a standalone search compatibility interface for specific Agents or coding tools. It is not a regular chat interface, nor a universal search entry point that all models can call.
Interface Information
| Configuration | Value |
|---|---|
| Endpoint | https://api.corerouter.cloud/v1/alpha/search |
| Method | POST |
| Header | Authorization: Bearer sk-... |
| Required Field | model |
| Model Requirement | Model ID from console with bound search capability |
Request body should use the search protocol corresponding to the calling client. The gateway will preserve unrecognized JSON fields and only rewrite the model field when model mapping is configured, so don't call it as a regular /v1/chat/completions request.
Applicable Scenarios
- Coding tools or Agents send search as an independent request.
- Client has already implemented the search protocol and needs to change request address to custom gateway.
- Need to separately meter or route search requests and regular conversation requests.
If your client just wants the model to use online search in the Responses workflow, prioritize reading Responses API Integration; don't manually convert regular chat requests to /v1/alpha/search.
Minimal Route Validation
The request below is only for confirming whether API Key, path, and model field can pass gateway validation. Real search requests need the client to supplement protocol fields it requires; a request with only model may be rejected by upstream.
export COREROUTER_API_KEY="sk-xxxxxxxxxxxxxxxx"
curl https://api.corerouter.cloud/v1/alpha/search \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $COREROUTER_API_KEY" \
-d '{
"model": "search-model-id"
}'Client Integration Points
- Change client's search Endpoint to
https://api.corerouter.cloud/v1/alpha/search. - Use search capability Model ID from console.
- Keep request body fields originally generated by the client; don't replace with Chat Completions'
messages. - First use client's debug logs to confirm final request path, authentication Header, and model name.
- If client also uses
/v1/responses, need to separately confirm Responses and standalone search capabilities; they are not the same switch.
Compatibility Boundaries
- Only channels and models configured with corresponding search capability can successfully forward; usually returns
400when no matching capability exists. - Upstream typically doesn't return standard token usage; gateway will meter as one search tool call; actual cost is based on console records.
- This interface doesn't guarantee streaming output support;
streamfield in request will be preserved and forwarded, but final behavior depends on upstream and client. - Search result structure, citation fields, and error format are determined by upstream protocol; cannot parse using Chat Completions'
choicesstructure.
Common Issues
Returns channel does not support /v1/alpha/search
Current route has no bound search-compatible channel. Switch to models explicitly marked as supporting search in console, or contact service maintainer to confirm if capability is configured.
Request Rejected by Upstream
Common cause is request body missing fields required by client protocol. Gateway only validates model; won't supplement complete search request structure for client. Use request body natively generated by client and check final model ID.
Why No Token Usage
Standalone search responses may not include standard usage field. Gateway will meter as one search tool call; when troubleshooting costs, refer to console consumption records.
