Get ready for the API
What to decide and prepare now so that day-one integration is a configuration exercise rather than a rewrite.
Last updated 2026-07-24
The gateway is designed to be OpenAI-compatible: a compatible request and response shape, not an affiliation. If your application already speaks that shape, most of the work is pointing a base URL at Webparam and swapping the key.
Decide your model strategy
There will be three ways to select intelligence, and choosing early shapes how you write your calls.
| Mode | What you send | Behaviour |
|---|---|---|
| Exact model | "deepseek/deepseek-v3.2" | Routes to an eligible endpoint serving that model |
| Fallback list | ["model-a", "model-b"] | Tries your preference, then an approved alternative |
| Routing preset | "webparam/auto" | Selects from an allowed pool under your policy |
Warning: Exact-model selection is the safest starting point. Automatic routing is only trustworthy once there is real usage, quality and latency data behind it. Plan to adopt it deliberately, not by default.
Structure projects and keys
Keys are scoped to a project and an environment, and carry their own model allow-list, spend cap and rate limit. Deciding your project boundaries now (one per application, per environment) means budgets and audit trails are meaningful from the first request rather than retrofitted.
Shape your calls
curl https://api.webparam.com/v1/chat/completions \
-H "Authorization: Bearer $WEBPARAM_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek/deepseek-v3.2",
"messages": [
{ "role": "user", "content": "Summarise this report" }
],
"stream": true
}'Illustrative: API not yet live
While the API is in build, you can explore the same models two ways: ask Echo how a request and response fit together, or browse the catalogue to compare pricing, context and capabilities.