Strike System

​

Prerequisites

• Deployment with the policies you want to score
• Policies with the right flagged content
• User metadata in your content checks
• A plan for how your app will apply the resulting action

​

Set it up

{
  "metadata": {
    "user": {
      "id": "user-123",
      "email": "user@example.com",
      "ip": "203.0.113.10"
    }
  }
}

​

How striking works in production

1. You send content checks with stable user identifiers.
2. White Circle evaluates policy violations and updates strike state.
3. White Circle calculates the current effective action for that user.
4. Your application applies that action and keeps it in sync over time.

​

How points and actions are calculated

1. If a session has multiple violations, only the violation with the highest severity contributes points for that session.
2. A strike contributes points until the strike expiration time configured in that severity level.
3. White Circle sums only active strike points for each user.
4. When the sum of active points exceeds an action threshold, that action is applied to the user.
5. The action expiration time is the later of the configured action duration or the moment when active points drop below that action’s threshold.
6. Permanent actions never expire.
7. Severity-level and action configuration changes are not retroactive. Existing strikes and actions stay unchanged, and updated settings apply only to new strikes and actions.

​

Worked example timeline

• Critical = 10 points, strike expires in 30 days
• High = 6 points, strike expires in 14 days
• Medium = 3 points, strike expires in 7 days
• Low = 1 point, strike expires in 3 days
• Warn threshold = 6 points, configured duration = 24 hours
• Suspend threshold = 10 points, configured duration = 3 days
• Ban threshold = 20 points, permanent

• configured action duration, and
• the moment active points drop below the threshold.

• Use Check Content for normal moderation traffic.
• Use Create Strike when you need to add strikes directly from your own workflows.
• Use Risk Scoring to fetch the current action and full strike history.
• Use Webhooks to react to real-time action changes (strike.action.updated, strike.action.expired).

​

Core endpoints

​

Appeals

​

Endpoints

​

Strike relationship

​

Typical flow

1. Create a strike with Create Strike or via session checks.
2. Let the user submit an appeal with Create Appeal.
3. Review the appeal in your tooling and track status with Get Appeal.
4. If outcome changes enforcement, consume webhook updates and apply the new action to the user account.

​

Next steps