safety_identifier in OpenAI Safety Usage Dashboard: API Field Guide and Routing Governance

OpenAI Safety Usage Dashboard changes a practical operating question for API teams: safety enforcement is no longer just a provider-side error that appears during a bad request. It is now a usage signal that teams can review by end-user identifier and fold into routing policy, support workflows, and abuse-response playbooks.

For organizations running multi-tenant AI products, that matters because one risky user can affect an entire provider relationship. If safety events remain invisible until a model call fails, operators can only react after the customer experience is already broken. The new dashboard makes blocked requests easier to inspect, but it also raises the bar for gateway-side identity, logging, and escalation design.

OpenAI Safety Usage Dashboard: what changed

OpenAI added the Safety Usage Dashboard to the API platform on June 23, 2026. The API changelog says the dashboard shows blocked Responses requests based on safety_identifier values sent with requests to identify end users. The related safety-checks guide explains why those identifiers matter: OpenAI can use them to associate risky activity with an individual end user rather than only with the organization as a whole.

The same guide says safety_identifier is available in the Responses API and Chat Completions API, while the Realtime API uses the OpenAI-Safety-Identifier header for the same concept. OpenAI recommends sending a stable hashed user ID, email-derived hash, or session ID for anonymous previews, and the help-center article says the new safety identifier supersedes the older user parameter for this purpose.

This is not just analytics. OpenAI’s safety guide describes escalating consequences when risky requests cross thresholds: delayed streaming while checks run, blocked access for an individual safety identifier, warnings to the organization, and potential loss of model access if violations continue. The dashboard gives operators a place to see the blocked side of that system instead of treating safety errors as isolated application logs.

Why OpenAI Safety Usage Dashboard matters for engineering teams

The immediate engineering issue is consistency. If one app path sends safety_identifier, another path sends the old user value, and a Realtime session sends neither, the dashboard will not line up with your internal tenant model. Teams that proxy traffic through an AI gateway should standardize safety identity at the edge before requests reach provider SDKs.

The second issue is privacy. A stable identifier is useful only if it is stable without exposing personal information. OpenAI explicitly recommends hashing internal IDs or emails. Gateway teams should make that hash deterministic across products, but avoid sending raw account IDs, names, email addresses, or customer metadata to the provider.

The third issue is incident response. A blocked request is not always a reason to ban an account, and a delayed stream is not always a provider outage. Support, trust-and-safety, and platform teams need a shared event vocabulary: user-level safety block, org-level warning, provider refusal, application moderation block, and ordinary rate-limit or quota failure should not collapse into the same “model failed” bucket.

This is where the OpenAI Safety Usage Dashboard connects to earlier platform changes. OpenAI already added inline moderation scores to API responses, which teams can use for application-side policy decisions. The new dashboard is different: it reports provider-side blocked requests tied to safety identifiers. Used together, inline moderation and dashboard review can separate proactive app controls from provider enforcement after a risky request is sent.

OpenAI Safety Usage Dashboard router/operator angle

For router and gateway operators, OpenAI Safety Usage Dashboard should become a routing input, not a screenshot someone checks after an incident. The routing layer can attach safety identifiers, log provider safety outcomes, and decide when to degrade, pause, escalate, or keep traffic on the same route.

A simple policy is to route by tenant and workload class first, then overlay safety state. For example, normal customer-support summarization, internal code review, and public user-generated prompts should not share identical escalation rules. If public prompts start producing repeated safety blocks, the gateway can require additional application moderation, shorter retention for risky inputs, or human review before retrying high-capability models.

Fallback also needs care. If OpenAI blocks a request because of a safety threshold, blindly falling back to another provider can turn a safety signal into provider shopping. A safer router treats provider safety blocks as policy events: preserve the audit trail, stop automatic cross-provider retries for the same risky payload, and require an explicit product rule before any alternative route is used.

Cost and reliability dashboards should also distinguish safety latency from normal latency. OpenAI’s guide says streaming can be delayed while additional checks run. If your gateway reports only total time-to-first-token, a safety delay may look like provider degradation. Tagging these events separately helps avoid false failover decisions and gives support teams a more truthful explanation.

What TheRouter users should watch or try

Teams using TheRouter-style gateway patterns should treat OpenAI Safety Usage Dashboard as a prompt to tighten identity propagation across the routing layer, not as a standalone console feature.

Use this checklist:

• Standardize safety identity at the gateway. Generate one deterministic, privacy-preserving safety_identifier per end user or anonymous session before requests enter provider-specific SDK code.
• Separate safety blocks from provider errors. In your AI routing layer, log safety blocks, refusals, rate limits, quota failures, and transport errors as different event classes.
• Do not auto-fallback blocked payloads. A provider safety block should require a policy decision, not an automatic retry on a different model.
• Connect dashboard review to moderation policy. Compare OpenAI Safety Usage Dashboard events with your application moderation signals and the earlier inline moderation API response changes.
• Prepare support language. A delayed stream, an individual user block, and an organization warning need different customer-facing explanations and different escalation owners.

OpenAI Safety Usage Dashboard is a narrow API-console feature on paper. Operationally, it is another sign that AI gateways need user-aware governance: not just which model to call, but which user, tenant, workload, and safety state should be allowed to reach that model in the first place.