Built-in actions
Two are always available:- Reject — the item is rejected. Fires the
queue_item.rejectedwebhook event. - Allow — the item is approved. Fires the
queue_item.allowedevent.
Custom actions
Beyond reject and allow, create custom content actions for any workflow you need — “Hide post”, “Send to legal”, “Escalate to senior moderator”, “Republish to homepage”. Custom actions appear in the queue alongside the built-ins and fire the genericqueue_item.action webhook event.
We recommend using actions for things like:
- Publish approved content
- Remove rejected content
- Route items into dedicated views (see Routing with views)
- Anything your moderation flow needs
Resolving an item when an action runs
An action can be configured to resolve the item automatically when it runs, removing it from the queue. This saves moderators a step — they don’t have to click “resolve” after taking an action.Adding a value
Actions can carry a value — a reason (“spam”, “harassment”), a category, a duration, or any free-text input. Configure the available values per action:- Predefined values — show a dropdown of options
- Free text — show a text input
- Both — predefined options plus an “Other” free-text fallback
Routing with views
You can use actions to route content into dedicated views. Create a view with an Action taken filter for a specific action, and any item that gets that action will appear in the view automatically — this is how escalation and user-report workflows are built.Running actions programmatically
Allow or reject content from your own systems with the allow content and reject content endpoints. Pass the content ID you sent when you submitted the content, or the ID Moderation API assigned. Trigger any other action — custom ones included — with the execute action endpoint. The built-in actions have the same key in every project:ITEM_ALLOW and ITEM_REJECT.
If no queueId is given, the item is resolved in the project’s default queue.
Recording decisions from your own review tool
If your moderators review content in your own tool, send their decision withmoderator — the user ID or email of a member of your organization. The action is recorded as theirs, and an allow or reject becomes a casebook case, the same as a decision in the review inbox.
createCasebookCase to choose yourself: false keeps a decision out of the casebook, and true adds a decision that names no moderator. Without either field, an action from the API is treated as automated and does not become a case.