Moderation

Moderation checks content users create in the app: one-to-one and group messages, chat room messages, nicknames and avatars, group profiles, group nicknames, messages in join and friend requests, and uploaded images, voice and video. Checks happen at three points:

• Before sending: text is checked before a message is written, and failing messages aren't sent.
• Before saving: profiles and requests are checked before being written, and failing ones aren't saved.
• Post-review: images, voice and video (and text, if configured) are reviewed after being sent or uploaded, and violations are recalled or blocked automatically.

Checks are based on word lists and third-party moderation services. Matches are rejected, replaced with * or sent for manual review as configured; users can also report content for your reviewers to handle in the console. Violations are recorded against users, and reaching the count you set triggers automatic mutes or bans.

This page explains moderation's rules and how they affect API calls and clients. Most settings are made in the console, see Moderation configuration; except for third-party moderation accounts, your server can also do them through APIs:

You want to	See
Add a batch of sensitive words, or let through words that were misjudged	Moderation config and word lists; rules in Word lists on this page
Test whether a piece of text would be blocked	Check text
Connect review items to your own review back office	Review items and violations
Automatically mute or ban after a number of violations	Violations and automatic penalties on this page
Handle message_rejected and content_rejected in clients	Errors callers see on this page
Check content your server submits too	Server-submitted content on this page

Defaults

New apps start with only platform rules in effect (see Platform rules and your rules); your rules are on for every scene but block nothing until you add word lists or turn on third-party moderation; there are no automatic penalties; client reporting is allowed.

What's checked and when

Scene	Content checked	When	How
message messages	Text in one-to-one and group messages: text in text, the file name name in file, name and address in location, every string value in a custom body (can be turned off); the files of image (including thumbnails), video (including covers) and voice	Before sending, batch sending and editing; after sending	Text is checked against word lists before sending, optionally with third-party text review before or after sending; images, voice and video are reviewed by a third party after sending
chatroom_message chat room messages	As above	Before sending; after pushing	As above. Pre-send checks for chat rooms take at most 200 milliseconds, and low-priority messages are only checked against word lists and get no post-review
user_profile user profiles	Nickname nickname; avatar avatar_url	Before creating users (including batch creation, client registration and automatic creation at ticket sign-in) and updating profiles	Text against word lists, optionally third-party text review; avatars optionally third-party review before saving
group_profile group profiles	Group name name, description description, announcement announcement; group avatar avatar_url	Before creating groups and updating group profiles	As above
group_member group nicknames	A member's group_nickname	Before changing a group nickname	Against word lists, optionally third-party text review
group_request join requests	The application reason, invitation message message (including invitations at group creation), and the reason reason for declining an application or invitation	Before applying, inviting and declining	As above
friend_request friend requests	The message message and add source add_source	Before sending a friend request	As above. The add source is an identifier, so matching a replacement word counts as rejection
chatroom_profile chat room profiles	Name name, description description, announcement announcement	Before creating and updating chat rooms	As above
chatroom_attribute chat room attributes	Attribute values	After setting	Only against word lists; violating attributes are deleted
media_upload uploaded files	User avatars, group avatars, chat room covers, and images, voice and video in group files uploaded to this service; group file names	After upload completes	Images, voice and video by a third party; group file names against word lists, with violations blocking the whole file

• Only changed fields are checked: profile updates only check fields that differ from the old value and aren't empty; clearing a field isn't checked. Old values already in a profile won't make unrelated changes fail because of words added later.
• Message attachments: images, voice and video in messages are reviewed in the message scene; violations recall the message and, for attachments stored by this service, also block the file. They aren't reviewed at upload.
• Not checked: custom attributes of users, groups and group members, message ext and push, friend remarks, group notices, the contents of documents, archives and similar files (only file names), and audio/video call content.
• Batch APIs: batch-sent messages are checked once and the result applies to every recipient; batch user creation only checks nicknames against word lists, with nicknames and avatars needing third-party review moved to post-review and violations cleared from the profile. Online-only messages are only checked against word lists.

Server-submitted content

Content your server (OpenAPI) and the console submit (creating users, updating group profiles, sending messages as users, setting chat room attributes and so on) is checked against platform rules only by default, not your word lists or third-party moderation: it's usually your business data and system notices, which you're responsible for.

To check it the same way, turn on "also check server-submitted content" for the scene in the console (not available for chatroom_attribute). Rejected server-submitted content doesn't count as any user's violation.

Platform rules and your rules

Every piece of content is checked against two sets of rules, and the strictest result wins:

• Platform rules: word lists maintained by the platform, plus third-party moderation categories the platform enforces (politics politics, terrorism terrorism and porn porn by default). Platform rules apply to all content in the app, including content your server submits, and can't be bypassed with allow words. Content matching platform rules is reviewed and handled by the platform: recalled messages have recalled.role platform, and you can't lift files blocked or bans made by the platform. See what the platform has done to your app under "Platform actions" in the console.
• Your rules: the word lists you maintain for the app in the console, the third-party moderation you turn on and per-category handling, each of which can be turned off per scene (leaving only platform rules for that scene). Matching content goes into your review items for your reviewers.

Platform word lists aren't visible to you. In the console's "Try it" and in review items, platform word list matches only show "platform rules" and the category, not the matched word.

Results

Result	From	Before sending or saving	Post-review
Reject	Word lists set to reject; third-party moderation suggesting block (can be changed to review per category)	Not written, and the caller gets an error, see Errors callers see. Counts as the author's violation when submitted by a client	Messages are recalled, files blocked, violating avatars cleared from profiles and chat room attributes deleted automatically; counts as the author's violation and creates a review item awaiting confirmation
Replace	Word lists set to replace (only your word lists)	The replaced content is written	Not applicable: post-review doesn't rewrite content already sent
Review	Word lists set to review; third-party moderation suggesting manual review (can be changed to no action per category)	Written as usual, with a review item created for manual review	A review item is created for manual review

When one check gives several results, the strictest wins: reject over replace, replace over review. When replace and review both apply, the replaced content is written and sent for review.

Replacement

Every character of the original from the first to the last character of a match (including symbols and spaces in between) becomes one *, and the rest is unchanged, so the content doesn't get longer. Everyone sees the replaced content, including the sender: the send API returns the replaced message, so clients should replace their local copy with the returned message after sending.

For example, with "笨蛋" in a word list set to replace, a user sending "你这个笨蛋，周末一起吃饭" gets this message object back:

{
  "conversation_id": "100311226008993792",
  "conversation_type": "single",
  "seq": 1,
  "message_id": "100311226034159616",
  "client_msg_id": "c-20261005-0002",
  "sender": "zhangsan",
  "sender_type": "user",
  "recipient": "lisi",
  "type": "text",
  "body": {
    "text": "你这个**，周末一起吃饭"
  },
  "ext": null,
  "mentions": null,
  "reply_to": null,
  "need_receipt": false,
  "exclude_from_unread": false,
  "reactions": null,
  "pinned": null,
  "edited": null,
  "recalled": null,
  "erased": false,
  "via": "client",
  "created_at": "2026-10-04T19:20:59.978Z",
  "message_version": 0
}

In custom messages, only matching string values in body are replaced; keys, other values and structure are unchanged, and ext isn't checked or rewritten.

Errors callers see

When content is rejected, message APIs return 403 message_rejected and profile and request APIs return 403 content_rejected. Errors don't include the matched word, so they can't be used to probe word lists:

code	Returned by	details
message_rejected	Sending messages, editing messages, sending chat room messages; per recipient in batch sends	reason
content_rejected	Creating users, updating user profiles, creating groups, updating group profiles, changing group nicknames, applying to and inviting to groups, declining applications or invitations, sending friend requests, creating and updating chat rooms	reason; field is the rejected field, the first one when several were rejected

Values of details.reason:

details.reason	Description
sensitive_content	Matched a word list set to reject
provider_block	Third-party moderation judged it a violation. With avatar review on, also returned when an avatar address isn't a publicly reachable http or https address, or is a blocked file
check_timeout	Deprecated: third-party review only runs after content is sent or saved, so content is no longer rejected for a timeout

Values of details.field: nickname and avatar_url for user profiles; name, description, announcement and avatar_url for group profiles; group_nickname for group nicknames; message and reason for join requests; message and add_source for friend requests; name, description and announcement for chat room profiles.

A rejected message:

{
  "error": {
    "code": "message_rejected",
    "message": "消息中含有不允许发送的内容",
    "details": {
      "reason": "sensitive_content"
    },
    "request_id": "N2RG5744A7XYFW5QUNLDECBBDG"
  }
}

A rejected nickname change:

{
  "error": {
    "code": "content_rejected",
    "message": "内容中含有不允许的内容",
    "details": {
      "field": "nickname",
      "reason": "sensitive_content"
    },
    "request_id": "MEOJNPL33UENE7ZSLOCTVCGMU5"
  }
}

An avatar failing third-party review:

{
  "error": {
    "code": "content_rejected",
    "message": "图片无法通过审核",
    "details": {
      "field": "avatar_url",
      "reason": "provider_block"
    },
    "request_id": "5HROKLWB343QARNZIKNMGOGZ4N"
  }
}

In batch sends, each recipient's result carries the same error; in batch user creation, rejected users appear in failed with code content_rejected.

When clients get either error, prompt the user to change the content according to details.reason, and don't automatically retry the same content.

Actions after delivery

When post-review finds a violation, or a reviewer confirms one, the content is handled by the relevant feature with the same effect as doing it through the API yourself:

• Recall messages: the content is cleared, and everyone who can see it in the conversation gets the recall, see Recall a message. recalled.role is server under your rules and platform under platform rules, so clients can show different notices.
• Block files: violating attachments, group files and avatars are blocked, and exchanging for download addresses returns file_blocked, see Download and manage files. Blocked avatars are also cleared from user, group and chat room profiles.
• Clear profiles: reviewers can clear violating nicknames, avatars, group profiles, group nicknames and chat room profiles. Fields are only cleared if they still hold the reviewed value, so later changes by the user aren't affected. Relevant clients are notified as for a normal profile change.
• Delete chat room attributes: only if the value hasn't changed.

Post-review usually finishes within a minute of an image being sent; voice and video depend on the third-party service, typically a few minutes. Messages are also checked against word lists once more after sending, so messages allowed through a failed pre-send check are recalled at this step if they match a reject word.

Word lists

Each app maintains its own word lists, added in the console (see Moderation configuration) or through the word list APIs. Word list properties:

Property	Values	Description
Kind	block, allow	Allow words fix misjudgments, see below
Action	reject, replace, review	Block lists only
Match mode	contains, exact	Exact: the whole normalized text must equal the word, suited to reserved nicknames (for example "官方客服" matches "官方 客服" but not "官方客服小王"). Allow lists can only use contains
Category	See Categories	Recorded in review items and violations on a match
Scenes	One or more scenes, or all	The list only applies in these scenes
Enabled	Yes, no	Disabled lists don't match, but keep their words

Normalization: before matching, text and words are normalized the same way, so words written with full-width characters, traditional characters, inserted symbols and spaces, or look-alike letters are still caught:

1. Full-width becomes half-width, and circled numbers, superscripts and other compatibility characters become plain characters.
2. Lowercase.
3. Traditional Chinese becomes simplified.
4. Whitespace, zero-width characters, combining marks, punctuation and symbols are removed, so "加 微 信", "加-微-信" and "加.微.信" all count as "加微信".
5. Common look-alike letters become Latin letters, such as Cyrillic а, о, р to a, o, p.

Words equal after normalization count as duplicates, for example adding "加v" after "加 V". Block words are 2 to 32 characters after normalization, allow words 2 to 64. Pinyin, homophones, split characters and look-alike Chinese characters aren't matched as variants, and regular expressions aren't supported; add common spellings as words, or use third-party moderation.

Allow words: a block word match that falls entirely within a longer allow word doesn't count. For example, blocking "加微信" and allowing "加微信公众号", "关注我们的加微信公众号" passes while "有需要请加微信" is rejected. Your allow words can't let through words rejected by platform rules.

When changes apply: changes to word lists and words usually apply within a second, at most 30 seconds. Verify right away with "Try it" in the console or Check text.

Each app can have up to 20 word lists with up to 10000 words each, 50000 words in total, and add or delete up to 1000 words at a time.

Third-party moderation

Word lists only catch known spellings. To recognize images, voice and video, or recognize text more accurately, turn on third-party moderation:

• Your own moderation account: add an account you opened with a moderation provider (Alibaba Cloud Content Moderation, Tencent Cloud Tianyu, NetEase Yidun) in the console, choose it for the app, and turn it on for the scenes you need. You settle fees directly with the provider. See Moderation accounts.
• Moderation provided by the platform: the platform can also turn on third-party moderation for some of the app's scenes, shown under "Platform settings" in the console. Reviews on the platform account count toward the app's usage, see Metered items; each app has a daily review limit (100000 by default), after which only word lists are used for the rest of the day.

Each piece of content is reviewed once: with your account if you turned on third-party moderation for the scene, otherwise with the platform's. One review's result is handled under both platform rules and your rules.

Review modes: each scene sets the mode for text and for media (images, voice, video) separately:

Mode	Description	Usable scenes
Post	Reviewed after sending, saving or uploading; violations are recalled, cleared or blocked	Text: every scene except chatroom_attribute and media_upload; media: message, chatroom_message, media_upload, and avatars in user_profile and group_profile

Third-party review always runs after content is sent or saved: sending and saving only check word lists and never wait for the provider, so provider latency, rate limits and outages never slow sending. The trade-off is that violating content is briefly visible until the review finishes; add words to a word list for content that must never go out. The old "Sync" mode has been removed and is treated as "Post".

Per-category handling: third-party moderation gives "suggest block", "suggest manual review" and categories. Per category you can set: on suggest block, reject (default) or review; on suggest manual review, review (default) or no action. Categories enforced by the platform aren't affected and are handled by platform rules.

Saving costs: review results for images, voice and video are cached by content digest, so an image forwarded many times is reviewed once; recalled and expired messages aren't reviewed; server-submitted content doesn't go to your third-party moderation by default (see Server-submitted content); each app sends at most 6000 items a minute to post-review, beyond which only word lists are used.

Image addresses: images at external addresses are fetched by the provider by address. Addresses that aren't publicly reachable http or https (internal addresses, unresolvable domains) aren't handed to the provider: avatars are rejected directly, and images in messages create a review item for reviewers to judge. Upload images to this service instead, see Files overview.

Manual review

These create review items for your reviewers in the console (see Review items), or your server can connect its own review system through the review item APIs:

• Content matching a word list set to review, or that third-party moderation suggests for manual review.
• Content acted on automatically in post-review, awaiting confirmation.
• Content users reported.

A message, a user's profile or a file has at most one unresolved item at a time, and later matches and reports join it. Reviewers can:

• Confirm a violation: choosing actions at the same time, such as recalling the message, blocking files, clearing profiles, or muting or banning the author; counts as the author's violation by default.
• No violation: closes the item. When an automatically actioned item is changed to no violation, the violations it caused are deleted and files it blocked are unblocked; recalled messages can't be restored, and mutes and bans already applied aren't lifted automatically.
• Escalate to the platform: when content may be illegal and needs the platform.

Within 30 days of a decision, "violation" can be changed to "no violation", for handling user appeals. Items unhandled for 30 days close automatically and can still be decided later. Content in an item is cleared 30 days after it closes, and the item is deleted after 180 days.

Violations and automatic penalties

These count as a user's violation:

• Content they submitted from a client was rejected before sending or saving.
• Their content was acted on automatically in post-review.
• A reviewer confirmed their content violates the rules (optionally not counted, for example when the account was hijacked).

Rejected content submitted by your server or the console doesn't count as any user's violation. Each violation records the scene, category, source and whose rules (the platform's or yours), and platform-rule violations count too. Violations are kept for 180 days and deleted with the user.

Automatic penalties: set up to 5 rules for the app in the console, such as "3 violations in 24 hours: mute one-to-one and group chats for 1 hour" or "10 violations in 7 days: ban for 7 days":

Item	Values
Time window	1 to 720 hours
Violation count	1 to 1000
Categories counted	All, or specific categories
Penalty	Global mute (choosing one or more of one-to-one, group and chat room scopes), or ban
Duration	1 second to 10 years, or permanent

After each violation, every rule counts the violations in its time window, and applies when the count is reached and the rule hasn't already penalized the user in that window. Penalties are applied as your app, with the same effect as calling global mute or ban user yourself: muted users get 403 user_muted when sending from clients; banned users' devices are all signed out at once. You can lift them anytime in the console or through the APIs. There are no rules by default, so no automatic penalties; the platform never penalizes your users automatically.

For example, after setting "3 violations in 24 hours: mute one-to-one and group chats for 1 hour", a user whose 3rd message is rejected gets this when posting in a group afterwards:

{
  "error": {
    "code": "user_muted",
    "message": "你已被禁言",
    "details": {
      "expires_at": "2026-10-04T20:23:49.532Z",
      "scope": "group"
    },
    "request_id": "OFQLWQXJWYXF2ZWQK6BU3S3CCW"
  }
}

In the console's "User violations", or with Get a user's violations and Clear a user's violations, you can see a user's violations and recent penalties and clear violations recorded under your rules (platform-rule violations can only be cleared by the platform). Clearing violations doesn't lift penalties already applied.

User reports

Users can report a message, a user, a group, a chat room or a chat room message. Reports go into your review items for reviewers; however many people report, it only raises the priority and never triggers automatic action.

• Only visible content can be reported: messages must be ones the reporter can see now (group messages from before joining or after leaving, or messages they deleted, don't qualify), and recalled messages can't be reported; private groups can only be reported by members, public groups by anyone; chat rooms don't require the reporter to be in them, but chat room messages can only be reported among the room's recent messages (within 24 hours); users can't report themselves or their own messages. Otherwise you get 404 not_found, indistinguishable from the target not existing.
• Evidence is kept: the reported content is saved at report time, so reviewers see it as reported even if the message is later recalled or the profile changed. Reports of users and groups can attach up to 5 messages as evidence.
• Repeat reports: the same person reporting the same target counts once, and reporting again returns the original report. New reports within 7 days of a target being judged no violation are recorded but don't reopen it.
• What reporters see: only "in progress" and "handled", never what penalty the reported person received.

Client reports: users report from clients with a User Token via POST /client/v1/reports, with the same parameters as Report on a user's behalf (without reporter; the reporter is themself); GET /client/v1/reports lists their reports from the last 90 days. Client reports are rate-limited per user: 5 a minute and 30 a day. Apps can turn off client reporting (runtime policy report_enabled, on by default); clients learn from the runtime config whether to show a report entry, and when off, client reports return 403 permission_denied with details.reason report_disabled. The SDKs wrap this.

Report reasons

reason	Meaning	Recorded category
ad	Ads, harassment	ad
fraud	Fraud	fraud
porn	Pornographic or vulgar	porn
politics	Political	politics
terrorism	Violence or terrorism	terrorism
abuse	Abuse or attacks	abuse
illegal	Illegal or prohibited	illegal
infringement	Infringement	other
minor	Involves minors	illegal
other	Other	other

Reports with reason fraud, politics, terrorism or minor, and reports whose reason falls in a category the platform enforces, get the highest review priority.

How it works with callbacks

Moderation and callbacks work together:

• Sync callbacks: the before-send callbacks (including chat room messages), before-add-friend and before-join-group callbacks all run after moderation checks. Requests rejected by moderation never reach the callback; for replaced content, the callback receives the replaced version; content rewritten by the callback isn't checked by moderation again. Pre-send checks plus the before-send callback take at most 3 seconds for messages and 500 milliseconds for chat room messages.
• Event callbacks: subscribe to moderation events to receive new review items (moderation.item_created), decisions (moderation.item_decided), user reports (moderation.report_created) and violations (moderation.violation_recorded, with any automatic penalty triggered, so you can notify or warn the user) on your server. Events don't include the reviewed content or matched words. Content reviewed by the platform is only notified when the platform confirms a violation.

Data structures

Categories

Word lists, third-party moderation results, reports and violations all use these categories. When content has several, the first in this table's order is the main category.

Category	Meaning
politics	Political
terrorism	Violence or terrorism
porn	Pornography
fraud	Fraud
contraband	Prohibited goods, such as drugs, firearms and controlled items
gambling	Gambling
abuse	Abuse, personal attacks
vulgar	Vulgar
ad	Ads and diversion (such as leaving contact details to pull people to other platforms)
illegal	Other illegal content
custom	Custom
other	Other