Data policy
How prompts and completions will be handled once the gateway is live, and what happens to them today, which is nothing.
Last updated 2026-07-24
Note: There is no API yet, so no prompts reach Webparam and none are stored. This page states the policy the gateway is being built to, so you can review it before you integrate rather than after.
A gateway sits between your application and a model provider, which means it necessarily sees your prompts in transit. That is a meaningful thing to ask of a customer, so the terms should be legible before you send the first request rather than buried in a subprocessor appendix.
What the gateway sees
To route a request, translate it into a provider's native schema and meter it, Webparam processes the request body in memory. To report usage, it records metadata about the call, which is a different thing from recording the call.
| Data | Purpose | Retained |
|---|---|---|
| Prompt and completion text | Routing and format translation | No |
| Token counts and cost | Usage reporting and billing | Yes |
| Model, provider and latency | Reporting and failover decisions | Yes |
| Key id and project | Attribution and access control | Yes |
Training
Webparam will not train models on your prompts or completions, and will not sell or share them. There is no plan for a setting that changes this, because a default that can be toggled is a default nobody trusts.
Providers handle data differently
This is the part a gateway cannot abstract away. Once a request reaches a provider, that provider's own retention and training terms apply, and they genuinely differ: some retain inputs for abuse monitoring for a fixed window, some offer zero-retention endpoints, some train on API traffic unless you opt out.
Warning: If your data cannot leave a jurisdiction, or cannot reach a particular vendor, pin your model choice explicitly and set a private-only routing preset rather than relying on automatic routing. Policy is a configuration decision, not a preference.
Key-level routing presets are designed for exactly this: a key can be restricted to an allow-list of models, or to providers that meet a data-handling bar, so the constraint is enforced by the platform rather than remembered by whoever writes the next call.
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.