> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vikat.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Request header prefix

> Gateway control headers are now x-vikat-*. The previous x-bf-* spelling still works.

## What changed

Every gateway control header now has an `x-vikat-` spelling:

| Before            | Now                  |
| ----------------- | -------------------- |
| `x-bf-vk`         | `x-vikat-vk`         |
| `x-bf-cache-key`  | `x-vikat-cache-key`  |
| `x-bf-session-id` | `x-vikat-session-id` |
| `x-bf-eh-<name>`  | `x-vikat-eh-<name>`  |
| `x-bf-<anything>` | `x-vikat-<anything>` |

The rule is mechanical: replace the `x-bf-` prefix with `x-vikat-`. Nothing else
about the headers changed — same names after the prefix, same values, same
behaviour.

## Do I have to change anything?

**No.** `x-bf-*` is still accepted on every endpoint and there is no removal date.
Requests, SDK calls, proxy rules and scripts using the old spelling keep working
exactly as before.

Use `x-vikat-*` for new integrations, and migrate existing ones when it suits
you.

## Mixing the two

Both spellings work at once, which is what makes an incremental migration safe:

* A fleet part-way through a rollout can have some clients on each spelling.
* If a single request carries both (`x-vikat-vk` and `x-bf-vk`), the
  `x-vikat-` value is used.
* Governance **required-header** checks and **CEL routing rules** see both names
  regardless of which the client sent. A rule written as
  `headers["x-bf-vk"] != ""` keeps matching a client that has migrated, and a
  rule written against `x-vikat-vk` matches one that has not. You do not need to
  update your rules in step with your clients.

## Header forwarding and the security denylist

The `x-vikat-eh-<name>` mechanism forwards `<name>` to the upstream provider. A
small denylist prevents that being used to override credentials, and it covers
**both** spellings — so `x-vikat-eh-x-bf-vk` and `x-vikat-eh-x-vikat-vk` are
refused alike, as are `x-api-key` and `x-goog-api-key`.

If you maintain a header allowlist or denylist of your own — in the console's
client settings, in a proxy, or in a WAF — add the `x-vikat-` spellings alongside
your existing `x-bf-` entries. A filter naming only the old prefix will not match
a migrated client.

## Why

These headers are the gateway's public interface. `x-bf-` came from the codebase
this gateway was forked from and does not match the product's name, which is
confusing in integration guides and in support conversations.

The change is being made now, before client SDKs ship, because an SDK freezes the
wire protocol into every application that installs it. Renaming after that point
is not practical.