---
outline: 2
head:
  - - meta
    - name: description
      content: Answers to common OneGateway questions on deployment, integration, API keys, quotas, billing, routing, semantic cache, guardrails, and troubleshooting.
---

# Frequently Asked Questions (FAQ)

This FAQ is for OneGateway members, including developers connecting applications, and for administrators. It covers integration, everyday use, and administration. If you're making your first request, start with the [Quickstart](/en/guide/getting-started). The menus and features you see depend on your environment's configuration and your role's permissions.

| What you want to know | Where to look |
| --- | --- |
| What OneGateway does, how it's deployed, and where data goes | [Product and deployment](#product) |
| How to connect applications and choose models | [Integration and models](#integration) |
| How keys, roles, departments, and group pricing differ | [API keys and permissions](#access) |
| Running out of quota, resets, redemption, and charges | [Quotas and billing](#billing) |
| Connecting providers, failover, and when configuration changes take effect | [Providers and routing](#routing) |
| `og-auto`, choosing models by complexity, model switching | [Intelligent routing](#intelligent-routing) |
| Whether caching saves money, and why a request missed the cache | [Semantic cache](#cache) |
| Content blocking, redaction, and streaming | [Guardrails](#guardrails) |
| Delayed logs, failed requests, and reporting problems | [Logs and troubleshooting](#troubleshooting) |

## Product and deployment {#product}

### What problems does OneGateway solve? {#product-purpose}

OneGateway is an AI gateway and token management platform built for enterprises. Employees, business applications, and AI agents reach models through a single endpoint, while administrators centrally manage provider connections, model access, API keys, spending quotas, and request records.

OneGateway handles model access and governance; the answers themselves are still generated by the connected upstream services. See the [Introduction](/en/guide/introduction) for its core capabilities.

### Why use OneGateway if we already have model provider accounts? {#existing-provider-accounts}

You can keep provider keys in one central place and issue each member and application its own OneGateway API key, so provider keys aren't scattered across applications. You can also set model permissions and spending limits in one place, review costs by member, department, or model, and connect several providers to the same model to split traffic and retry failed requests.

### What deployment options are available, and where does business data go? {#deployment-data-flow}

OneGateway supports SaaS and hybrid deployment. SaaS uses OneGateway's cloud service. In hybrid mode, you run a dedicated Token Gate inside your own network, which suits connecting internal models or managing API traffic inside your organization.

When a hybrid deployment calls models on your internal network, request and response content can stay inside your network, while management data such as configuration, quotas, and usage syncs with the cloud console. **Where data actually goes also depends on where supporting services run**: requests to external models are sent to those model services, and if you enable external embedding services, moderation models, or verdict services, the relevant text is sent to them too. Confirm where these dependencies run when planning your deployment. See [Deployment Options](/en/guide/introduction#deployment-modes).

### What do the console and the gateway each do? Which URL should applications use? {#console-and-gateway}

The console is where you manage users, permissions, configuration, reports, and audit logs. The gateway (Token Gate) handles live requests: converting between API formats, routing, checking and deducting quota, and running any enabled plugins.

Do everyday administration in the OneGateway console. Point applications at the **API URL** shown on the API Keys page.

## Integration and models {#integration}

### What do I need to connect an application? How much code has to change? {#integration-requirements}

You need three values: the **API URL, a OneGateway API key, and a model ID**. Get the first two from the API Keys page, and copy the model ID from Available Models.

If your application already uses a compatible API format, you usually only need to swap in the new URL, key, and model ID. If you rely on provider-specific parameters or features, also check that the selected model and connection type support them. See the [Quickstart](/en/guide/getting-started) for complete examples.

### Should the API URL include `/v1`? Which model name should I use? {#api-url-and-model-id}

It depends on your client: some expect a base URL, others the full request URL. In the Quickstart's OpenAI-format example, an SDK takes the base URL `https://your-api-endpoint/v1`, while a direct HTTP chat request uses the full URL `https://your-api-endpoint/v1/chat/completions`. Some clients add the path automatically, so check how yours behaves to avoid adding `/v1` twice.

Set `model` to the **model ID** shown in [Available Models](/en/user/models), not the display name on the model card or the provider's name. Virtual model names provided by your administrator (such as `og-auto`) are the exception: they can be used directly even though they are not listed in Available Models; see [virtual models](#virtual-model).

If an administrator has set up model name mappings, the upstream model shown in [Request Logs](/en/user/usage#viewing-one-call-s-details) may differ from the model ID you requested. A different name on its own doesn't mean the request failed; ask an administrator to check that provider's mapping configuration.

### Can we connect self-hosted models? Do all models support the same features? {#self-hosted-models}

Yes, you can connect self-hosted models that use a compatible protocol, as long as the gateway can reach their service address and an administrator configures the matching connection type, credentials, and model.

A single endpoint doesn't change what a model can do. Context length, tool calling, image, audio, and reasoning support still depend on the target model and protocol. The context and price fields in a model definition are for description and billing; changing them doesn't extend the model's capabilities. See [Providers & Models](/en/admin/providers-and-models).

### Why can a colleague see or use a model that I can't? {#model-access}

Members can have different model access. First check your own Available Models page, then check the model restrictions on your API key. An administrator should also confirm that the model has an enabled provider with the key's group pricing selected.

**Seeing a model on the page doesn't mean every API key can use it.** Restrictions on a key can narrow access further. See [Group Pricing and API keys](/en/admin/providers-and-models#assigning-group-pricing-to-an-api-key).

### What do gray model status blocks or a price of `--` mean? {#model-status}

A gray block means there are no request records or monitoring data for that time period. It doesn't by itself mean the model is unavailable. The status reflects recent requests to the model as a whole, and doesn't guarantee that your next request will succeed.

A price of `--` means that price item hasn't been configured; it doesn't mean the request is free. Models billed per request show `—` as the output price. See [Reading a Model Card](/en/user/models#reading-a-model-card).

## API keys and permissions {#access}

### How is a OneGateway API key different from an upstream provider key? {#api-key-types}

Administrators maintain upstream provider keys in the provider connection settings, and the gateway uses them to reach model services. A OneGateway API key is what a member or application uses to reach the gateway. Each OneGateway key belongs to a specific member and is subject to the platform's permission and quota rules.

Create a separate key for each application so you can give each one its own quota, expiry date, allowed models, and IP restrictions. That makes it easier to track each application's spending and to disable just one application. See [API Keys](/en/user/tokens).

Each account can create only a limited number of keys. If creating a key fails because the limit has been reached, ask an administrator to check it. Before deleting existing keys, confirm that no application still uses them.

### Do "Unlimited quota" and "All models" mean an API key has no restrictions? {#unlimited-key}

No. "Unlimited quota" only means the key has no spending cap of its own. Requests are still subject to the member's quota, account balance, and other access rules.

"All models" means no extra model allowlist has been set on the key. An enabled provider must still serve the target model, so it doesn't grant access to every model on the platform.

### What do roles, departments, and group pricing control? {#roles-and-groups}

| Setting | What it controls |
| --- | --- |
| Role | Which menus a person sees and which actions they can take |
| Department | Who belongs where, used to analyze usage and costs by department |
| Group pricing | Which pricing ratio applies to calls |
| API key restrictions | Narrower limits on models, spending, expiry, and source IPs for one application or purpose |

Changing a member's department doesn't automatically change their role, group pricing, or quota. After you change a user's group pricing, also review any API keys that have group pricing explicitly assigned. How group pricing is selected and managed depends on your deployment and permissions. Environments where the platform manages group pricing centrally may not offer manual controls; in that case, ask an administrator to check the applicable pricing ratio. See [Group Pricing](/en/admin/providers-and-models#group-pricing).

### How do I cut off access after a key leak or when an employee leaves? {#revoke-access}

If a key may have leaked:

1. Turn the key off, but keep it so its history is available for investigation.
2. Create a replacement key and update the application.
3. Delete the old key once it's no longer needed. Deletion can't be undone.

When an employee leaves, an administrator should deactivate their account and check the status of their API keys, then confirm that the configuration has synced and that requests using the old credentials are rejected. Don't rely on canceling their quota alone: the account may still have a balance it can spend.

If semantic caching is enabled, test two kinds of request separately: ones that would hit the cache, and ones that must go to the upstream model. A successful credential check before cache lookup is cached for 5 minutes by default. So a console toggle alone doesn't prove that every path rejects the old credential immediately, and the 5 minutes isn't a guaranteed revocation deadline either. If the old credential still gets answers, an administrator should check configuration sync and Token Gate's credential validation status. Replacing the key in an application doesn't by itself invalidate the old one. See [Credential Validation and Revocation Checks](/en/guide/semantic-cache#credential-validation-and-revocation-checks), [Managing API Keys](/en/admin/tokens), and [Maintaining and Deactivating Users](/en/admin/users#maintaining-and-deactivating-users).

### Why does the same API key work on some machines but not others? {#machine-specific-failures}

First check whether the key's **IP restrictions** include each machine's actual outbound IP address. Behind a proxy or network address translation (NAT), that address may differ from the machine's private IP. Then compare the API URL, model ID, and key on each machine, and check that each one can reach the gateway.

## Quotas and billing {#billing}

### How do member quotas, account balances, and API key quotas differ? {#quota-types}

| Type | Where it comes from and what it does | Resets each period? |
| --- | --- | --- |
| Member quota | A recurring spending limit an administrator assigns to a member | Yes |
| Account balance | Credit added with redemption codes, drawn down as you spend | No |
| API key quota | An extra spending cap on a single key | Not automatically (it doesn't follow the member quota's cycle) |

All three are **amounts of money**, not token counts. `$` means US dollars: a `$100` quota allows $100 of spending.

Requests draw on the member quota first and fall back to the account balance when the quota runs short. Members without a configured quota spend from their balance directly. Throughout, the API key's own quota applies independently. See [Quotas and Balance](/en/admin/quota#quotas-and-balance).

### Why does a new account's first request fail with insufficient quota? {#new-account-quota}

Creating an account or API key doesn't give you a spending quota by itself. Check your [Personal Dashboard](/en/user/my-dashboard) to see whether a member quota has been set and whether you have any balance. If you have neither, ask an administrator to [assign a quota](/en/admin/quota#assigning-quotas), or, if redemption codes are enabled in your environment, [redeem a valid code](/en/user/redemption) to add balance.

After a quota is assigned or balance is added, also check the API key's own quota and the configuration sync status before trying again. Don't conclude it's a quota problem from the HTTP status code alone.

### Do requests always stop when a member quota runs out? Why do I get an insufficient-quota error when I still have balance? {#exhausted-quota}

When a member quota runs out, requests can continue if the account balance covers them. Canceling the member quota doesn't clear the balance either.

Conversely, **an exhausted API key quota blocks requests even if the member still has quota or balance left**. When troubleshooting, check all three (member quota, account balance, and key quota) and whether configuration has synced. The amount shown as used may also lag behind actual spending.

### When do quotas reset? Does unused quota carry over? {#quota-resets}

The available reset periods are the ones shown in your environment's quota settings. Weekly quotas reset at 00:00 every Monday, and monthly quotas at 00:00 on the 1st of each month. If a daily option is offered, it resets at 00:00 every day.

Resets follow the gateway server's time zone, not your computer's or your organization's time zone settings. Check the **Next reset** time shown in the console.

Unused member quota doesn't carry over to the next period, and you can't choose a custom reset date or time. Balance added with redemption codes isn't affected by resets. See [Period Resets and Usage Notifications](/en/admin/quota#period-resets-and-usage-notifications).

### If I raise a quota, does the amount already used this period still count? {#quota-adjustments}

No. Saving a quota change ends the current period and starts a new one. **The amount used so far resets to zero**, and the quota and next reset time are recalculated from the new settings.

It doesn't simply add the new amount to what's left in the current period. The same form also saves notification settings, so saving a change to notifications alone resets the period too. See [Adjusting and Canceling Quotas](/en/admin/quota#adjusting-and-canceling-quotas).

### If I assign quotas by department, does the department share one pool? Do new members get it automatically? {#department-quotas}

No. Choosing a department is just a quick way to select members in bulk. When you save, each selected member gets their own quota. For example, selecting 10 people with a $100 quota each gives each person $100 for the period.

People who join the department later don't get that quota automatically. An administrator needs to find them in the unconfigured members view and assign a quota separately. Moving a member to another department doesn't change their existing quota. A bulk save can partly succeed: use the failure details to fix only the members whose quotas failed, so you don't adjust the successful ones twice.

### Why is there no redemption page? Does redeeming a code increase my member quota? {#redemption}

Redemption codes have to be enabled in your environment. Organizations usually use either member quotas or redemption codes, not both. If you don't see the page, check your quota on your [Personal Dashboard](/en/user/my-dashboard) and contact your administrator.

A successful redemption adds to the signed-in account's **balance**. It doesn't raise your recurring quota or reset what you've used this period. Each code can be redeemed only once. If a code won't redeem, ask an administrator to check whether it has been used, has expired, has been disabled, or doesn't apply to you. See [Redeem a Code](/en/user/redemption).

### How are charges calculated? Why can requests to the same model cost different amounts? {#billing-calculation}

Models are billed either by token usage or per request. Usage-based billing can include separate prices for input, output, cache reads, cache creation, images, and audio, with the applicable pricing ratio applied.

Differences in input and output length, cache usage, pricing ratio, or billing configuration can all change what a request to the same model costs. To check a charge, expand the record in [Request Logs](/en/user/usage#viewing-one-call-s-details) to see the prices, usage, pricing ratio, and calculation used. Don't estimate the charge by multiplying total tokens by a single price.

### Does "Subscription" in a log's cost column mean the request was free? {#subscription-charge}

No. "Subscription" means the request was deducted from the member's recurring quota. When a request is paid from redemption-code balance, the cost column shows the actual amount charged. To check recurring quota consumption, see your [Personal Dashboard](/en/user/my-dashboard); for a single request's billing details, expand its log record.

## Providers and routing {#routing}

### Why can requests to a model fail after a successful provider connection test? {#connection-test}

The connection test mainly calls the provider's model-list endpoint to check connectivity and discover models. It doesn't confirm that every model can generate responses, and it doesn't check members' permissions.

Also check that the provider is enabled, its supported models are correct, the matching group pricing is selected, and the API key's restrictions allow the request, then send a real request. If the test succeeds but there are no models to select, first check whether model definitions with matching names exist in the current instance. See [Testing the Connection and Selecting Models](/en/admin/providers-and-models#testing-the-connection-and-selecting-models).

### How can several providers serve one model? What's the difference between priority and weight? {#routing-priority}

Several providers can serve the same model. Providers with higher priority values are chosen first. Providers at the same priority split traffic by weight, and lower priorities act as backups.

For example, two providers at the same priority with weights of 3 and 1 have roughly a 3/4 and 1/4 chance of being chosen; a small number of requests won't necessarily split exactly 3:1. **Priority and weight are part of the provider's configuration**, so changing them in one model's routing view also affects every other model that provider serves. See [Model Routing](/en/admin/providers-and-models#model-routing).

### Does adding a backup provider guarantee failover will work? {#failover}

No. Failover depends on which errors trigger a retry, the retry limit, the backup provider's health, group pricing configuration, and whether the model is available. Administrators should test against the actual retry policy and check in Request Logs which provider finally handled the request.

When providers switch, applications usually keep using the same model ID.

### Is creating a model definition enough to use the model? What happens when a model is disabled? {#model-definitions}

No. A model definition holds the model's name, context, description, and prices; actually using the model also requires a provider connection. An administrator needs to add the model to a provider's supported models, then check the group pricing, the enabled state, and the sync result.

Disabling a model removes it from the supported models of the relevant providers in the current gateway instance, which affects any requests that depend on it. After re-enabling it, check again which providers serve it and whether it has synced. See [Model Marketplace](/en/admin/providers-and-models#model-marketplace).

## Intelligent routing {#intelligent-routing}

These answers cover common integration questions. For more detail, see the [Intelligent Routing FAQ](/en/guide/intelligent-routing#faq).

### What is `og-auto`, and why can't I find it among the available models? {#virtual-model}

Names such as `og-auto` are **virtual models** the administrator configures in [Intelligent Routing](/en/guide/intelligent-routing): you send them in requests, and the gateway rewrites them to an actual model by request complexity or by rule. Virtual models map to no provider, so they do not appear in [Available Models](/en/user/models), but you can use them directly in requests; ask your administrator which virtual models are available.

### How do I know which model actually served my request, and which model is billed? {#routed-model}

Rely on the `og-route-model` response header: it is the model sent to the provider after routing, and billing follows it; the billing details in the [request logs](/en/user/usage) are authoritative for the actual cost. The `model` in the response body is the model name reported by the provider, which may differ when the provider maps models or uses versioned names, so do not use it to check prices. The model you originally requested is in the `og-route-requested-model` response header, present only when the model was rewritten.

### Using `og-auto` returns 403 or "no access to model". What should I do? {#routing-403}

When an API Key restricts available models, it is checked against the **actual model** after rewriting. Add the model shown in `og-route-model` to the key's available models; better still, ask the administrator for every model the virtual model may use and add them all at once. A 403 does not trigger a switch to a backup model.

### Does the gateway switch models automatically when the primary model fails? {#routing-fallback}

Yes, when the administrator has configured backup models for the rule. With the default policy, it switches when the model has no available provider, on 429 rate limiting, on 500 / 502 / 503 / 529, or on connection failure; 504 / 524 timeouts, unpriced models, missing permissions, insufficient quota, and sensitive-word rejections do not switch, nor do some upstream internal errors whose cause cannot be determined. Administrators can adjust the switching policy. Streaming requests switch only before output starts. See [Automatic Switching on Failure](/en/guide/intelligent-routing#automatic-switching-on-failure). When a switch happens, the `og-route` response header is `FALLBACK` and `og-route-attempts` is greater than 1.

## Semantic cache {#cache}

These answers cover common integration questions. For more operational detail, see the [Semantic Cache FAQ](/en/guide/semantic-cache#faq).

### Is semantic caching the same as a provider's prompt caching? Does it always save money and time? {#cache-benefits}

No. On a semantic cache hit, OneGateway reuses a previous answer, so the target model doesn't generate anything. A provider's prompt caching usually still runs generation and only reuses part of the input processing.

Semantic lookup may need an embedding request, and a miss still goes to the target model. So the actual benefit depends on your hit rate, how long entries stay cached, and the lookup overhead. It works best for stable, frequently asked questions; be careful enabling it for real-time information, user-specific information, or tasks that need a fresh creative result each time. See [Semantic Cache](/en/guide/semantic-cache).

### Why did an identical or similar question miss the cache? {#cache-misses}

Matching also depends on the API credential, cache key, endpoint, streaming mode, model, and generation parameters, and similar questions must also meet the semantic threshold. The first successful answer is written to the cache in the background, so an immediate retry can still miss. Expired entries, requests with more messages than the configured limit, or entries that were never written can also prevent a hit.

Check the `og-cache` response header: `HIT` means a match was found, and `MISS` means a lookup ran but found no match. If the header is missing, check that the caching prerequisites are met and that any proxy preserves response headers. A threshold of `0.8` is a matching cutoff, **not an 80% accuracy score for the answer**. See [Troubleshooting by Symptom](/en/guide/semantic-cache#troubleshooting-by-symptom).

### How do I force a fresh answer? Do old entries expire automatically when our knowledge changes? {#fresh-answers}

Use a new, unused value for `hcd-og-cache-key`, or ask an administrator to clear the relevant entries. When your knowledge base changes, you can switch the business key from `product-faq:v1` to `product-faq:v2`.

`hcd-og-no-store: true` only stops the current answer from being stored; it can still read old entries. To get a fresh answer without storing it, use a new cache key together with No-Store. Changing the default TTL doesn't expire existing entries right away, and a hit doesn't extend an entry's lifetime. See [Lifecycle and Cleanup](/en/guide/semantic-cache#lifecycle-and-cleanup).

### Do different users share cached answers? {#cache-isolation}

Not if they use different API credentials or cache keys. Users who share both the same credential and the same cache key may get the same cached answers. If you need isolation, have a trusted application set a separate business key for each.

The tenant header that callers can set is only a business identifier; it doesn't replace authorization. See [Cache Spaces and Matching Boundaries](/en/guide/semantic-cache#cache-spaces-and-matching-boundaries).

### Can streaming and Responses API requests be cached? Is the `usage` in a cache hit what this request consumed? {#streaming-cache}

Semantic caching supports Chat Completions, Anthropic Messages, and stateless Responses requests, including streaming. Responses requests that use `background: true`, `conversation`, or a non-empty `previous_response_id` skip the cache, and `/v1/responses/compact` doesn't use it at all.

Streaming and non-streaming responses are cached separately, and partial answers from interrupted streams aren't stored. **The `usage` in a replayed response is historical data.** It doesn't show what this request consumed upstream or what it was actually charged, and a cache hit doesn't mean the total cost was zero. See [Semantic Cache](/en/guide/semantic-cache) for supported APIs and how usage is counted.

## Guardrails {#guardrails}

### What do guardrails check? Can they detect sensitive content in images, audio, or files? {#guardrail-coverage}

Guardrails check the text in requests and responses according to administrator rules. Use them to redact sensitive information, detect prompt injection, and moderate content. They check text blocks in multimodal messages but skip image, audio, and file blocks themselves. If that content needs checking, extract its text in your application first.

Reasoning content and some tool arguments also have coverage limits, so enabling guardrails doesn't mean every part of a request is checked. See [Known Boundaries](/en/guide/guardrails#known-boundaries).

### Does a request blocked by guardrails still incur model usage? {#blocked-usage}

A block on the request side happens before the request reaches the target model, so it incurs no generation usage from that model. For a block on the response side, it depends where the answer came from:

- **An answer generated upstream for this request**: the model has already generated some or all of it. The upstream usage still counts and isn't reversed by the block.
- **An answer replayed from the semantic cache**: output guardrails still check it, but the target model did not generate a new answer for this request. The historical `usage` in it isn't new usage, and it doesn't mean the total cost was zero.

If a guardrail calls a separate moderation model, that check can incur usage of its own, counted separately from the target model's usage. See the [Guardrails FAQ](/en/guide/guardrails#faq).

### How can I tell a guardrail block from other failures? Why did a streamed answer stop partway? {#guardrail-errors}

A guardrail block has the error type or code `guardrail_blocked`. Non-streaming blocks return HTTP 400 by default, though administrators can change this status code, so check the error body and the `og-guardrail` header as well. If output is blocked after streaming has started, an error event is sent and the stream ends; content already delivered can't be recalled.

**Streaming response headers only reflect the request-side result.** Use SSE error events and server logs to determine the output-side result. If there's no evidence of a guardrail block, also check for network or upstream interruptions. See [What Callers See on a Block](/en/guide/guardrails#what-callers-see-on-a-block).

### Will a moderation service failure block traffic? Can I observe matches before turning on blocking? {#moderation-failures}

If a check fails to run, the request is allowed through by default and the error is logged. To block requests when moderation fails, set `fail_on_error: true` on the check, enable `deny: true` on its guardrail, and make sure the severity assigned to the failure meets the blocking threshold. **Recording a failure as a violation doesn't guarantee a block.** Plugin-level exceptions are handled separately by `error_policy`, which doesn't replace the check-level settings. Letting a request through isn't the same as passing the check, so administrators should monitor `outcome=error` events.

You can start with `deny: false` to watch what gets matched before turning on blocking. Note that this observation mode turns off blocking but **doesn't turn off redaction**. See [Gradual Rollout](/en/guide/guardrails#gradual-rollout) and [Relationship with Other Capabilities](/en/guide/guardrails#relationship-with-other-capabilities) for how these settings behave.

### Can cached answers bypass guardrails? {#cached-answer-checks}

Not with the required plugin order. Requests pass through guardrails before cache lookup, and answers pass through output guardrails before they're cached. Cache hits also go through the output guardrails that apply to the current request.

Guardrails don't scan or clean out entries already in the cache. To remove old content, clear the cache or switch to a new cache key version. See [Relationship with Other Capabilities](/en/guide/guardrails#relationship-with-other-capabilities).

## Logs and troubleshooting {#troubleshooting}

### Why can't I find a request I just made in the logs? Why don't dashboard figures match current spending? {#delayed-logs}

For requests forwarded to a model service, quota is checked and deducted in real time, but request logs, usage totals, and runtime fields in the console arrive through background sync tasks, so they lag behind. These records usually appear in Request Logs after about two minutes, and aggregate statistics may update at a different time.

**Cache hits and request-side guardrail blocks don't necessarily create upstream request records**, so waiting for that sync isn't enough. Use the Request ID to check Token Gate request logs, cache monitoring, or guardrail events. These plugin logs and statistics require the logging plugin and matching storage to be enabled, and where you query them depends on your environment's console integration. If they weren't being recorded, waiting or refreshing won't bring back those past events.

If you can't find a log, first check the time range and user filters. Logs show the last 7 days by default; the main list keeps the last 30 days, and older records are under **Historical Data**. If records are still missing, ask an administrator to check the sync status. See [Request Logs](/en/user/usage).

### Can members see other people's requests? How do administrators track configuration changes? {#data-access}

Regular members can only see their own request records and personal statistics. Administrators see organization data within the scope they're authorized for, and can analyze costs and usage by department, member, model, and more.

Request Logs tracks model requests; the audit log tracks administrative changes, such as who changed an API key, provider, price, or routing policy. The two serve different purposes. Members can use their [Personal Dashboard](/en/user/my-dashboard); administrators can use [Dashboard & Analytics](/en/user/dashboard).

### Is a 429 or rate-limit error coming from OneGateway or the provider? {#rate-limits}

It could be either. If platform rate limits are enabled, requests can be limited per tenant, per API key, or globally. An upstream provider can also limit requests for its account or model. HTTP 429 alone doesn't tell you which layer applied the limit.

Keep the error body, response headers, timestamp, and Request ID, and ask an administrator to match them against Token Gate request logs, rate-limit rules, and upstream responses. Platform rules are checked by an administrator with the right permissions; upstream limits mean checking the provider account's limits and status.

In your application, reduce request frequency and concurrency, and back off between retries. If the response includes `Retry-After`, wait as long as it says. Adding retries or a backup provider doesn't guarantee you'll get around the current limit.

### In what order should I troubleshoot a failed request? {#troubleshooting-order}

Save the full error details first, then work through the symptoms below. Don't judge the cause from the HTTP status code alone.

| Symptom | Check first |
| --- | --- |
| Can't connect, or path not found | API URL, paths your client adds automatically, network access |
| Invalid or expired key | Full key value, whether it's disabled or deleted, expiry date, owner account status |
| Model not found or access denied | Model ID, the key's group pricing and model restrictions, whether a provider serves the model and is enabled |
| Insufficient quota | API key quota, member quota, account balance, configuration sync |
| Fails on only some machines | IP restrictions, actual outbound addresses, network path |
| 429 or rate-limit error | [Where the limit comes from](#rate-limits), platform rules, upstream limits, retry delay |
| Timeout or upstream error | Error details, the provider that handled the request, provider health, retry policy |
| `guardrail_blocked` | Guardrail ID, match events, whether the block was request-side or response-side |
| No change after saving configuration | Sync or hot reload result, then a new test request |

Use the minimal request from the [Quickstart](/en/guide/getting-started) to confirm the URL, key, and model, then add back your application's other parameters step by step. Administrators can also follow [Verification and Troubleshooting](/en/admin/providers-and-models#verification-and-troubleshooting).

### What should I include when reporting an issue to an administrator? {#reporting-issues}

Include the time (with time zone), the Request ID if you have it, the model ID, API key name, endpoint path, whether the request was streaming, the HTTP status, and the error details. Describe how widespread the issue is and whether you can reproduce it consistently. For cache issues, include response headers such as `og-cache`; for guardrail issues, include the guardrail ID and any streaming error events.

Redact request samples before sharing them. Don't include full API keys, upstream credentials, or unrelated sensitive business data. Administrators can use these details to match your report against request logs, plugin events, and configuration change records.