Your gateway, proxy or chat client already speaks the OpenAI-compatible format. That is the point of the format. A new provider is a configuration entry, not a new code path. So adding WebWright is the same move you make for any other compatible provider. The only questions are what the entry needs to contain, and how you confirm it works for both chat and transcription.

What a provider entry needs

Every OpenAI-compatible client reduces a provider to the same three inputs: a base URL, an API key, and a model name. If your project already lets a user add a provider, those are the fields it collects, and WebWright fits the same shape.

  • Base URL. The endpoint your client appends paths to, such as /chat/completions.
  • API key. The bearer token your client sends in the Authorization header.
  • Model name. The model id the provider serves, read from the provider's model list rather than guessed.

The base URL

WebWright publishes an OpenAI-compatible base URL at https://webwright.ai/v1. It serves chat completions and audio transcription, so one entry covers both. Point the entry at it:

{
  baseURL: "https://webwright.ai/v1",
  apiKey: "<key>",
  model: "<model from /v1/models>"
}

Use the exact object shape your project already expects. The example above is the common shape; some clients spell the fields base_url, api_key and model. The values are the same.

Confirm it works

Two calls confirm the entry end to end: one chat completion and one transcription. Both go through the same base URL and the same key, so a passing pair proves the entry is wired correctly.

A chat completion first:

curl https://webwright.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <key>" \
  -d '{
  "model": "wren-r1",
  "messages": [
    {"role": "user", "content": "Say hello in one line."}
  ]
}'

A successful call returns the usual completion shape:

{
  "object": "chat.completion",
  "choices": [
    {"index": 0, "message": {"role": "assistant", "content": "Hello."}, "finish_reason": "stop"}
  ]
}

The model value wren-r1 is the id that GET https://webwright.ai/v1/models returns. Read it from there rather than hard-coding it, so a model change is a config edit.

Then the same key on a transcription, through the same entry:

curl https://webwright.ai/v1/audio/transcriptions \
  -H "Authorization: Bearer <key>" \
  -F "file=@meeting.mp3" \
  -F "model=<transcription model from your dashboard>" \
  -F "response_format=json"

Which returns the transcript:

{
  "text": "This is the transcript of the audio file."
}

Two calls, one base URL, one key. If both return, the provider entry is complete.

If your users bring their own key

Many gateways and client apps let each user supply their own key. In that model, the provider entry is the integration. You add WebWright once as a provider, and each user pastes the key they created for their own account. The key belongs to the user, so usage and billing stay with them and nothing changes on your side. You are not reselling access. You are adding one more provider your users can point at.

Where to get a key and the model list

Create a key in the WebWright dashboard, then list the models that key can use with one call:

curl https://webwright.ai/v1/models \
  -H "Authorization: Bearer <key>"

The response lists the model ids to place in the provider entry. Copy the id into the entry rather than hard-coding it, so the entry stays a configuration value.

If you want a second set of eyes on the entry and the two calls that confirm it, book a short consult and we will walk the request path with you.

The WebWright Team