REST API

https://api.wicarax.app

This is the intended production API origin. For local development, use your configured local API origin, commonly http://localhost:4000.

Every request carries the agent key as a bearer token. The key identifies the agent, so no request ever names one.

Authorization: Bearer wcx_sk_YOUR_SECRET_KEY

curl https://api.wicarax.app/v1/chat/completions \
  -H "Authorization: Bearer $WICARAX_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "wicarax-zenith",
    "messages": [
      { "role": "user", "content": "What is your refund policy?" }
    ]
  }'

The response is a complete JSON body:

{
  "id": "chatcmpl-...",
  "object": "chat.completion",
  "created": 1769500000,
  "model": "wicarax-zenith",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Example answer based on your sources."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 1254,
    "completion_tokens": 20,
    "total_tokens": 1274
  }
}

The request and response shapes follow the OpenAI chat completions format, so libraries and tools that already speak it need two changes: the base URL and the key. What they must not do is send parameters this API has not implemented: those are refused, not ignored, so a client configured with its usual defaults will get a 400 until they are removed.

import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: process.env.WICARAX_SECRET_KEY,
  baseURL: 'https://api.wicarax.app/v1',
});

const completion = await client.chat.completions.create({
  model: 'wicarax-zenith',
  messages: [{ role: 'user', content: 'What is your refund policy?' }],
});

• The model field is required and must be exactly wicarax-zenith. Anything else, including omitting it, is refused with 400 model_not_found. It does not select a model, because there is only one; it is a contract check that stops a client believing it chose something.
• Default parameters are the common first failure. An OpenAI client or framework that sends temperature, max_tokens, stop or tools by default will be refused with 400 unsupported_parameter, and param will name the offending field.
• Streaming is not supported. Sending stream: true is refused with 400 and the code streaming_not_supported, rather than being silently ignored, so a client cannot believe it opted in and then mis-parse the body.
• system messages are refused, not dropped. They return 400 unsupported_parameter, because silently discarding a system prompt lets a caller believe they steered the assistant. Behaviour comes from the dashboard, not from the request.

Exact numbers per plan are on Rate Limits, and every status and code is on Errors.

Failures use the OpenAI error envelope:

{
  "error": {
    "message": "Access denied for this request.",
    "type": "authentication_error",
    "param": null,
    "code": "access_denied"
  }
}

All four fields are always present. param names the request field at fault on a 400, and is null when no single field is to blame.

A malformed key, an unknown key, an inactive agent and a disallowed origin all answer with the same 403 access_denied. That is deliberate, so a scraped key cannot be confirmed by the response. Check the credential type, key state, agent state, and allowed origin before retrying.