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

# Reseller program

> Apply for Floodgate reseller access, identify your customers in API requests, and understand customer restrictions, account cooldowns, and safety pauses.

The Floodgate reseller program lets you identify the customers using your service. When a customer breaks a safety policy, Floodgate can restrict that customer on Standard Claude/GPT. Repeated refusals across your customers can still put your whole account on cooldown.

You use ordinary Floodgate API keys, routing groups, and billing. Approval does not add a separate reseller balance, membership, special pricing, or dedicated reseller keys. Your [account limits and key budgets](https://docs.floodgate.dev/routing-groups.md) still apply.

## Apply for access

1. Sign in and open [Profile](https://floodgate.dev/profile).
2. Find **Reseller program**.
3. Describe your service in 10 to 2,000 characters. Do not include personal data.
4. Enter your expected customer count, from 1 to 1,000,000.
5. Accept the customer ID contract and submit your application.

The contract requires stable customer IDs without personal data. Changing an ID to evade a restriction violates the reseller terms.

| Application status | What it means |
| - | - |
| Not applied | You can submit an application. The API reports this as `none`. |
| Pending | Your application is waiting for administrator review. |
| Approved | You must identify customers on the required endpoints. You can open Customers in the sidebar. |
| Rejected | Read the review note in Profile. You can apply again. |
| Revoked | Contact support before applying again. |

Submitting an application does not enable reseller access. Only approval does. If the Customers link has not appeared after approval, refresh your account or sign in again. You can also open [Customers](https://floodgate.dev/customers) directly.

## Identify each customer

Send exactly one `X-Floodgate-Customer-Id` header with a stable reference for the end customer making the request.

| Rule | Requirement |
| - | - |
| Length | 1 to 128 characters |
| Allowed characters | ASCII letters `A-Z` and `a-z`, digits `0-9`, underscores `_`, and hyphens `-` |
| Case | Case-sensitive. `customer_42` and `Customer_42` are different IDs. |
| Stability | Keep the same ID for that customer across requests, conversations, and your API keys. |
| Privacy | Use an opaque reference such as `customer_42`. Do not send names, email addresses, message content, or other personal data. |

Floodgate stores the customer reference you send. Keep the mapping between that reference and your customer in your own service. Do not use a conversation ID as a replacement for a stable customer ID.

For approved resellers, the header is required by default on these endpoints:

| Method | Endpoint |
| - | - |
| POST | `/v1/chat/completions` |
| POST | `/v1/messages` |
| POST | `/v1/responses` |
| POST | `/v1/responses/compact` |

This requirement depends on the endpoint, not the model or routing group. Floodgate administrators can change the required endpoint list.

An empty, invalid, or duplicate header is rejected on every model API endpoint for an approved reseller, including endpoints where the header is optional. If your account is not approved, the header has no effect.

Dashboard Playground requests are exempt. On Playground and optional endpoints without a customer ID, provider refusals use account-level enforcement. Leaving out the ID does not bypass account safeguards.

### Send a request

Use your model API key, not your Personal Access Token. This example identifies `customer_42` in a Responses request:

```bash theme={null}
curl "https://api.floodgate.dev/v1/responses" \
  -H "Authorization: Bearer $FLOODGATE_API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-Floodgate-Customer-Id: customer_42" \
  -d '{
    "model": "gpt-6-sol",
    "input": "Explain binary search in two sentences.",
    "max_output_tokens": 256
  }'
```

Add the same header to your Chat Completions, Messages, and Responses compaction requests. See the [API guide](https://docs.floodgate.dev/openai-compatible.md) for their request formats. Your integration should attach the correct customer ID to each request.

## Customer restrictions and account cooldowns

The rules below are the defaults introduced with the program. Administrators can change thresholds and durations. Use the actual expiry in an API error or the Customers page when deciding when to retry.

Restrictions apply to Standard Claude/GPT across all of your API keys. They run before safety screening and model dispatch. Other models and routing groups remain subject to their own availability and policies.

### Safety screening blocks

Floodgate can check a request before sending it to the model. A screening block counts against the identified customer. It does not start an account cooldown or count toward the shared safety pause.

| Screening blocks for one customer in a rolling 24 hours | Customer restriction |
| - | - |
| Fewer than 5 | No timed restriction from this ladder. The unsafe request is still blocked. |
| 5 or more | 15 minutes, level 1 |
| 10 or more | 1 hour, level 2 |
| 20 or more | 24 hours, level 3 |

The screening ladder only receives blocks when screening is enabled and the request is in its configured scope. A screening service failure is separate from a policy block.

### Model safety refusals

A model safety refusal happens after a request reaches a model route. Qualifying refusals on protected Claude/GPT routes count toward customer restrictions, account cooldowns, and the shared safety pause.

| Trigger | Result |
| - | - |
| One qualifying refusal for an identified customer | Restrict that customer for 24 hours, level 3 |
| Two qualifying refusals across your account within a rolling hour | One-hour account cooldown on Standard Claude/GPT |
| Third separate account cooldown within a rolling 24 hours | 24-hour account cooldown and an administrator alert |

Account counts combine all of your customers and keys. Changing customer IDs, API keys, or conversations does not reset them. When an approved reseller has no customer ID on an exempt request, a qualifying refusal starts an account cooldown directly. That cooldown also counts toward repeated account cooldowns.

Refusals for other model families do not enter these Claude/GPT counters. Those requests still follow their own safety policies.

### Repeated restrictions

A customer's third separate level 3 restriction within seven days becomes a seven-day restriction, level 4. Level 3 restrictions from either screening blocks or model refusals count toward this rule.

An active restriction of the same or a higher level is not stacked or extended by another event. A higher-level restriction can still replace the effective limit with a longer restriction. An active account cooldown is not restarted by duplicate refusals.

Expiration ends that timed restriction. It does not make a paused route available, clear another active restriction, or erase recent events from rolling counts.

If five distinct customers on your account receive restrictions within 24 hours, Floodgate alerts administrators to review possible ID rotation. The alert is limited to once per reseller per 24 hours. It is a review signal, not proof that you changed IDs.

## Shared Standard safety pause

Floodgate also has a shared safety pause for Standard Claude/GPT. By default, three qualifying model refusals within a rolling hour across all users trigger it. This includes accounts outside the reseller program.

The pause affects Standard Claude/GPT for everyone. It has no automatic end time and no `Retry-After` date. Only a root administrator can resume access. Waiting for your own customer restriction or account cooldown to expire does not lift the shared pause.

You can use another available routing group that permits your request. Other Standard model families remain available under their usual rules. After administrators resume Standard Claude/GPT, earlier refusal events do not immediately trigger the newly reset pause.

## Check your customers

Open [Customers](https://floodgate.dev/customers) to see:

* Your account cooldown status, remaining time, and end time.
* Your recent qualifying refusal count and account threshold.
* The number of customers with active restrictions.
* Restrictions with the customer ID, reason, level, expiry, and status.
* Recent violations with their time, customer ID, reason, model, and request ID.

Use **Customer ID lookup** with the exact, case-sensitive reference. The page starts with active restrictions. Choose **Show history** to include expired and lifted restrictions.

This is a restriction and violation view, not a list of every customer in your service. Resellers cannot lift their own restrictions or account cooldowns. Contact support if you need a review, and include the customer reference and request ID without sharing your API key.

You can read the same information through the [reseller account API](https://docs.floodgate.dev/api-reference/reseller.md).

## Notifications

Customer restriction notices use your configured notification channel, such as email, webhook, Bark, or Gotify. A notice includes the customer ID, reason, level, and expiry.

Webhook integrations can receive the `customer_restriction` event. Notification limits apply per reseller and customer, so one customer's notices do not suppress another customer's notices. Repeated notices for the same customer can be limited.

Administrators can disable these notifications. Delivery is best effort, so use the Customers page or API as your source of current status.

## Conversation reuse and privacy

Keep Responses conversations attached to the same customer. If another customer on your account sends a `previous_response_id` belonging to the first customer, Floodgate can flag an informational link for administrator review. This also applies when continuing through Responses compaction.

This signal does not block a request, restrict a customer, or prove evasion. It is independent of the chat ID header.

Detection covers native Responses routes that return the original response ID to your client. It does not cover Chat Completions, Messages, or conversions that create replacement IDs or hide the original ID.

For this detection, Floodgate stores a keyed hash of the response ID, not the plaintext ID or conversation messages. Response ownership expires after 30 days by default. Administrators can set retention from 1 to 90 days or disable tracking. Detection is best effort and can miss events. Expired ownership is ignored; physical deletion can happen later. Customer links and restriction histories are retained separately.

## Handle errors

Read the HTTP status, error code, and message. For timed restrictions, honor `Retry-After`, which gives the remaining wait in seconds. The customer restriction message includes the customer, reason, level, and expiry.

| HTTP | Error or condition | What to do |
| - | - | - |
| 400 | `customer_id_required` | Add the stable customer header to the required endpoint. |
| 400 | `customer_id_invalid` | Check length and characters. Send exactly one nonempty header. |
| 403 | `customer_restricted` | Wait for that customer's restriction to expire or use another permitted, available route. Honor `Retry-After`. |
| 403 | `policy_account_cooldown` | Wait for the account cooldown to expire. Honor `Retry-After`. |
| 403 | `policy_account_escalated` | Repeated cooldowns caused a longer account restriction. Honor its expiry and `Retry-After`. |
| 503 | Standard Claude/GPT is paused | Read the pause message. Use another available route or wait for administrator resumption. There is no automatic expiry. |
| 403 | `policy_moderation_blocked` | Revise the request to comply with the safety policy. |
| 503 | `policy_moderation_unavailable` | Safety screening could not complete. Retry later. |
| 403 | `session_blocked_by_cyber_policy` | Review the safety refusal before retrying. Do not rotate customer or conversation IDs to evade it. |

The request that triggers a refusal can report the refusal itself. Later requests can report the resulting restriction or pause. If a refusal arrives after streaming has started, the HTTP status already sent cannot change to a later 403. Floodgate can still record the event and restrict future requests.

Accounts outside the reseller program retain ordinary account enforcement. One qualifying model refusal starts a one-hour Standard Claude/GPT cooldown. Adding a customer header without approval does not change that behavior.

## Moving from the old reseller program

The previous reseller keys and `reseller_*` account groups are retired. The release removes legacy reseller API keys and moves those accounts to the default account group. Those keys cannot be reused.

Create and [configure ordinary API keys](https://docs.floodgate.dev/routing-groups.md), then apply through Profile for the current customer identification program. Approval does not restore the old reseller wallet, membership, or pricing program.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.