Content Safety

Requests failing all of a sudden, with nothing changed on your side? A content safety rule may have paused your traffic for a while. This page explains what sets that off, how long a pause lasts, and what to do about it.

What content safety screening is

Every request you send through OfoxAI ends up at a model run by an upstream provider such as OpenAI, Anthropic or Google. Each provider screens the text, images and files it receives against its own usage policies and rejects anything that fails. OfoxAI adds one more layer: when a single account keeps sending requests that get rejected, the platform pauses that account’s traffic for a while instead of forwarding more of it.

The pause protects two things: your account’s standing with the provider, and the shared routes that every OfoxAI customer depends on.

It is not a rate limit

Speed quotas are covered in Rate Limits, and status codes in general in Error Handling.

Why ordinary workloads get flagged

Two kinds of content get rejected: content that genuinely breaks a provider’s usage policy or the OfoxAI Terms of Service , and content that an automated classifier reads as breaking them. The second kind is where most surprises come from.

The patterns we see most often:

• Retrying a rejected request. A script gets one rejection, retries the same prompt four more times, and turns a single flag into five. This is the fastest way to reach the first threshold below.
• Batch jobs over text you did not write. Scraped pages, user reviews, support transcripts and PDF dumps carry material nobody has read.
• End-user input passed straight through. If your app forwards whatever a visitor types, sooner or later somebody types something that gets flagged.
• Long conversations. The whole history goes back to the model on every turn, so one flagged message keeps counting until you drop it.
• False positives. Portrait photos, medical questions, security research and fiction all get misread sometimes. Providers do not agree with each other either: material rejected on one model can pass on another.

How the ladder works

Two things decide what happens: how many flagged requests you collect in a short window, and how many times your account has been paused before.

Thresholds that start a pause

Flagged requests are counted in sliding windows. Reaching any one of these starts a pause:

How long a pause lasts

Each pause is longer than the one before it:

A typical sequence: a batch job collects five flags inside a minute and is paused for 5 minutes. It restarts on the same data, collects five more, and the second pause is 15 minutes. Cleaning the data after the first pause is what breaks the cycle.

While a pause is in effect, the affected requests are refused at the gateway instead of being sent to the model, and a refused request costs you nothing. When the timer runs out, access returns on its own. You do not have to contact anyone to reactivate it.

The count does not follow you forever: stay clean for long enough and the next pause starts again at the first step. If flags keep coming after the longest pause, the account goes to human review, and under the Terms of Service  service can be limited or suspended.

What to do

If you are paused right now

1. Stop the traffic. Pause the job and turn off automatic retries. Retrying does not shorten a pause.
2. Find the flagged requests. Open the Logs page in the console , filter to the minutes around your first failure, and look for rejected requests.
3. Fix the source. Remove or rewrite the content, and make sure the same input cannot be resubmitted by a retry loop or a queue.
4. Wait out the timer. Access comes back by itself.
5. Restart small. Send a handful of requests and check the results before releasing the full batch.

How to keep it from happening again

• Treat a rejection as final for that exact input. Log it, skip it, move on. Never loop on it.
• Filter user input before it reaches the model, especially in a public-facing product.
• Sample imported or scraped data by hand before running it at scale.
• Drop flagged turns out of long conversations instead of resending the whole history.
• Give separate workloads separate API Keys, so the Logs page shows you straight away which job caused the problem.

If you think it was a mistake

Classifiers do get it wrong. Write to support@ofoxai.com with:

• the email address on the account
• when the blocked requests happened, including your time zone
• the model you were calling
• one or two request IDs from the Logs page

Do not include your API Key, your password, or more customer data than the review needs. We will look at what triggered the flag and tell you what we can about it.

The email you may receive

When a restriction is applied, OfoxAI may write to the address registered on your account. A genuine notice comes from an OfoxAI address (@ofoxai.com or @ofox.ai), refers to your account, and says what was restricted, how long it lasts and what to check.

After you get one:

• Sign in to the console yourself instead of following a link in the message, and check Logs for the period the email mentions.
• Fix the content before restarting the job. The email tells you what happened; it does not clear anything for you.
• Reply to it, or write to support@ofoxai.com, if you believe the flag was wrong.

What OfoxAI never asks for:

• your API Key, password or a verification code
• a payment or an “unlock fee” to lift a restriction
• moving the conversation to a personal email address or a chat app

Any message that asks for one of those is phishing, whatever the sender line says. Forward it to support@ofoxai.com and delete it.