---
title: "xAI safety_identifier: Keep One User from Sinking Your API Key"
description: "xAI added an optional safety_identifier field in September 2026 so policy violations map to one end user, not your whole API key. How to generate and send it."
url: https://cdnping.org/en/blog/xai-api-safety-identifier
language: en
published: 2026-10-18
category: "Developer tools"
tags: ["xAI","Grok API","safety_identifier","compliance","multi-tenant apps"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# xAI safety_identifier: Keep One User from Sinking Your API Key

The xAI developer release notes added an optional request field, `safety_identifier`, in September 2026. Your app puts an opaque identifier for each end user into the request. When xAI handles a request that violates its usage policy, it can attribute that request to the specific end user instead of the whole API key. If you build a SaaS product, a bot, or an internal team tool where many users share one key, the official docs recommend setting this field per user.

> Time frame: this article reflects xAI's official documentation as of October 17, 2026. The release-notes entry is listed under a September heading and the page gives no exact date, so check the official page.

## What exactly is safety_identifier?

According to the [xAI release notes](https://docs.x.ai/developers/release-notes), it is "an opaque identifier assigned by your application that represents the end user," and the request field is optional. The goal is to attribute violations to a specific user, so one user's abuse no longer implicates the entire account.

The [official Security FAQ](https://docs.x.ai/developers/faq/security) adds a few points:

- The identifier should be stable: the same user gets the same value on every request. Your application assigns it; end users must not be able to set it themselves.
- If a request violates the usage policy, xAI can attribute it to this identifier and reference it when contacting you.
- Send an internal user ID, or a hash of another opaque value. Do not send an email address, phone number, or nickname. The page says the field's format is not validated and mentions a length limit of 96 characters.
- If many end users share one API key, set the field for each of them so abuse reports land on the user rather than on the key.

## Which endpoints support it? Does the old user field still work?

The two official documents list these supported surfaces: Chat Completions, the Responses API (the FAQ says this includes streaming and WebSocket mode), deferred chat completions, the Batch API, and gRPC `GetCompletionsRequest`.

The existing `user` field is still accepted, but the FAQ states that `safety_identifier` is the field the docs recommend going forward. The docs do not say what happens if you send both, so do not rely on that behavior. In new code, send only `safety_identifier`. When migrating old code, replace `user`.

## What happens if you do not send it?

The docs do not describe the consequences of omitting it, and they do not say xAI will reject requests that lack it. What we can say is the design intent: without an identifier, a violating request can only be attributed at the key level. For a multi-user app, adding the field costs little, and the benefit is that the blast radius shrinks when something goes wrong. Whether it actually prevents a key from being restricted depends on how xAI handles the case, and the official docs make no such promise.

## How should you generate the identifier?

The principles are: stable, irreversible, and free of personal information. A common approach is a keyed hash (HMAC) of your internal user ID, so nobody can work backward from the identifier to your user ID. The following is an example, not official code:

```python
import hmac, hashlib, os

SECRET = os.environ["SAFETY_ID_SECRET"].encode()

def safety_id(internal_user_id: str) -> str:
    return hmac.new(SECRET, internal_user_id.encode(), hashlib.sha256).hexdigest()
```

Notes:

- Do not rotate the secret casually. Once it changes, the same user gets a different identifier and attribution history is broken.
- Use the internal ID, not the email address. A user changing their email should not change their identifier.
- In bot scenarios, a group or a channel is not a user. Map to the real end user wherever possible.

## How do you put it in a request?

The field goes in the request body. The example below uses the Responses endpoint, with a placeholder for the model name; fill in the name you see on the official models page:

```bash
curl https://api.x.ai/v1/responses \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<model>",
    "input": "Hello",
    "safety_identifier": "a1b2c3d4e5f6..."
  }'
```

If you use an OpenAI-compatible SDK, its type definitions may not include this field yet. You can pass it through the SDK's "extra request body" parameter (`extra_body` in the OpenAI Python SDK); the details depend on your SDK version:

```python
client.chat.completions.create(
    model="<model>",
    messages=[{"role": "user", "content": "Hello"}],
    extra_body={"safety_identifier": safety_id(user.id)},
)
```

For where the field goes in Batch and gRPC requests, see the official API docs; this article does not cover them.

## Pre-launch checklist

1. Every code path that calls xAI sends the field: chat, batch jobs, background tasks, and scheduled tasks all count.
2. The value is a hash or a random ID, with no email address, phone number, or nickname.
3. The value is the same for every request from one user and different across users.
4. Your logs record the request ID, the identifier, and the time, but you do not keep users' raw content in plaintext for long. When something goes wrong, you can use the identifier to find out which user it was.
5. Moderate content up front. The identifier only handles attribution; it does not block violating content for you. Input moderation, rate limiting, and banning abusive users remain your responsibility.
6. State in your terms of service that violating use may lead you to restrict that user's access.

## How do you track later changes to xAI's docs?

The semantics of a field like this may get more detail later. cdnping's [Changes](/en/changes) page monitors additions and removals in official changelogs and pricing pages across providers, and [xAI API status](/en/status/xai) shows the health of the API itself. For more approaches, see [How to find out the moment an LLM API price changes](/en/blog/track-llm-price-and-model-changes).

If you are comparing direct access, cloud-provider hosting, and access through a gateway, read [How to choose how to access AI APIs](/en/blog/official-api-vs-cloud-vs-gateway). When requests pass through an intermediate layer (in China, commonly called an "API relay" or "zhongzhuan" service), the upstream sees the relay's key, so you have to do end-user attribution yourself; for how to evaluate relays, see [How to choose an API relay](/en/blog/api-relay-how-to-evaluate). When you hit errors, the methods in [How to read the OpenAI and Claude status pages](/en/blog/how-to-read-ai-status-pages) also help you tell whether it is an upstream incident.

## Sources

- [xAI Developer Release Notes](https://docs.x.ai/developers/release-notes)
- [xAI Security FAQ: how to identify which end user caused a violation](https://docs.x.ai/developers/faq/security)