HiAPI Content Policy Violation (CONTENT_POLICY_VIOLATION): Causes and Fixes

When you submit a generation task through HiAPI's unified async task API and your prompt or input assets fail the safety review, you will receive the business error code CONTENT_POLICY_VIOLATION. The official documentation describes its meaning as "content failed the safety review," and the recommended action is "adjust the prompt or input content and retry." It is neither an authentication issue nor a balance or parameter issue—the content itself was blocked. This article explains what it looks like, where you can see it, and how to fix it.

1. Symptom

Content policy rejections appear in two forms, depending on whether the block happens at submission time or during task execution. CONTENT_POLICY_VIOLATION is a business error code of the unified async API and shares the same enumeration as the synchronous error_code returned when creating a task and the data.error.code in a task's terminal state (it is not marked as "creation-only," so it can appear in both places).

Form A: Synchronously rejected at creation. The content fails review when you call POST /v1/tasks, and a failure envelope is returned with error_code set to CONTENT_POLICY_VIOLATION. The envelope looks like this (based on the official documentation's failure response; code is the HTTP status and error_code is the business code):

{
  "code": 400,
  "message": "...",
  "data": null,
  "error_code": "CONTENT_POLICY_VIOLATION"
}

In this case you do not get a taskId—the task was never created.

Form B: The task runs and ends in a fail terminal state. The task is judged non-compliant only after you have obtained a taskId and the task has started running. When you poll GET /v1/tasks/{taskId}, the HTTP status is still 200 (the envelope message may even be success, which only means "this query succeeded," not that your task succeeded), and the real failure is hidden inside data:

{
  "code": 200,
  "data": {
    "taskId": "tk-hiapi-...",
    "status": "fail",
    "error": { "code": "CONTENT_POLICY_VIOLATION", "message": "..." }
  },
  "message": "success"
}

The one-sentence diagnosis rule: do not look only at the HTTP status code. Read in three layers—HTTP status (was the request accepted) → business error code (error_code / data.error.code, why it was rejected) → task status (how far data.status got). As long as the code field (the synchronous envelope's error_code or the terminal state's data.error.code) is CONTENT_POLICY_VIOLATION, it is a content review block—not the same thing as a timeout, broken link, or parameter error. The message text may vary slightly by scenario; the stable, diagnosable signal is this code, so do not regex-match the message text.

When the same kind of block is triggered in Playground / the model page's "online trial," the page shows an inline "failed safety review" message instead of handing you the code to parse yourself—this is a presentation difference between the web trial (synchronous) path and the API path you call from your code.

2. Common causes (from highest to lowest probability)

1. The prompt contains disallowed content. This is the most common cause. NSFW / adult content, explicit violence and gore, and similar content are blocked by the safety review. Note that many models explicitly do not support NSFW content, and some models (such as GPT Image 2) also follow their provider's content policy (e.g., the OpenAI content policy).
2. Input images / reference assets failed review. In image-to-image (i2i), reference-image-to-video, and similar tasks, it is not only the prompt that is reviewed—the images and reference assets you upload or reference must also pass review. A clean prompt with a non-compliant input image will still produce CONTENT_POLICY_VIOLATION.
3. Switching models lands you under a stricter policy. Different models have different levels of strictness in their content policies. It is normal for the same prompt to pass on model A and be rejected by model B, especially in sensitive areas such as realistic portraits, celebrity likenesses, and brand / copyrighted material.
4. Mistaking a rejection for another error. A genuine content block is treated as "the service is glitching" and retried unchanged over and over—the same content will never pass no matter how many times you retry; you are just wasting time.

3. Fix steps

1. First confirm the error code. Read the exact code from the synchronous response's error_code or the task terminal state's data.error.code. Confirm it is CONTENT_POLICY_VIOLATION, not TASK_FAILED (generic failure, usually a transient issue or an unreachable input image link) or INVALID_REQUEST (invalid request body). Different codes require completely different fixes.
2. Clean up the prompt item by item. Remove NSFW / adult, explicit violence, and similar expressions, replace them with compliant wording, and resubmit. The changes must be targeted, not just random word deletion.
3. Check all input assets. For image-to-image / reference-based generation, replace any input images or reference images that may trigger review—they must pass review just like the prompt.
4. Check the target model's policy. Go to that model's page to see its stated restrictions (for example, the GPT Image 2 model page explicitly states "does not support NSFW content, follows the OpenAI content policy"); if you need to switch models, you can compare each model's capabilities and policies in the model marketplace.
5. Retry after making changes. The documentation's recommended action for this code is to "adjust the prompt or input content and retry." Note: failed tasks are not charged—the quota reserved at creation is fully refunded once the task reaches the failure terminal state, so a task blocked by review itself costs nothing; however, resubmitting the same violating content unchanged will not pass, so change it first and then submit.

4. Minimal verification example

If you first want to rule out "is there a problem with my key / integration," send a POST /v1/tasks with an obviously compliant prompt and see whether you can normally obtain a taskId (use the bare id gpt-image-2 for model):

curl -s -X POST "https://api.hiapi.ai/v1/tasks" \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2",
    "input": { "prompt": "a cozy coffee shop storefront at sunrise, warm light" }
  }'

• Returns {"code":200,"data":{"taskId":"tk-hiapi-..."}} → your key and integration work; therefore the problem with the previously rejected request lies in the content, so go back to Section 3 and clean up the prompt / input image.
• Returns HTTP 401 + {"error":{"code":"permission_denied",...}} → this is an authentication issue (wrong key / missing Authorization: Bearer), not content policy.
• Even a compliant prompt returns error_code: "CONTENT_POLICY_VIOLATION" → this is relatively rare; re-examine whether the prompt contains sensitive words you overlooked, or try a more neutral description.

5. Further reading

• The complete business error code table for the unified async API (including the meanings and recommended actions for CONTENT_POLICY_VIOLATION, TASK_FAILED, INVALID_REQUEST, and others): Unified Async API documentation.
• To confirm a model's content restrictions: check the corresponding model page or the model marketplace.

6. FAQ

Q: What is the difference between CONTENT_POLICY_VIOLATION and TASK_FAILED? A: The former means the content failed the safety review, and the fix is to change the prompt / input assets; the latter is a generic failure, most commonly caused by an unreachable input image / video URL or transient fluctuation, and the fix is to fix the URL / retry. They are different business error codes, so do not confuse them. Reading error.code tells them apart.

Q: Will I be charged if a task is rejected by the content policy? A: No. According to the documentation, once a task reaches the failure terminal state, the quota reserved at creation is fully refunded. A task blocked by review itself incurs no cost.

Q: For the same prompt, why does the web "online trial" show an explicit "failed review" message while the API only gives me a code? A: The web trial is a synchronous path and displays the review result directly as an inline message; the API path puts the result in the response body's error_code / data.error.code, for your code to read and branch on. The information is the same, only the presentation differs.

Q: I only changed the prompt and left the input image untouched—why is it still rejected? A: The safety review covers input assets, not just the prompt. For image-to-image / reference-based generation, also replace any input images or reference images that may trigger review.

Q: Does HiAPI have a public "content policy" page I can check? A: There is no standalone content policy page. Each model's content restrictions are written on its model page (for example, "does not support NSFW content"), and platform-level terms are in the Terms of Service and Privacy Policy.

Q: Can repeated retries "get past" it? A: No. The same violating content will never pass no matter how many times you retry; it only wastes polling. First change the content as described in Section 3, then submit.