> ## Documentation Index
> Fetch the complete documentation index at: https://docs.polymorfa.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Safety actions and restrictions

> Distinguish project Health-rule actions, operator controls, and restrictions observed from WhatsApp.

Polymorfa keeps three facts separate:

* a present Health estimate and its source;
* an action configured by your project or an operator; and
* a restriction observed from WhatsApp.

A low or unavailable Health value does not by itself prove that WhatsApp has
restricted a number. An observed provider outcome appears through
`bansafe.enforcement` and the number's incident history.

## Project Health-rule actions

Configure one rule per project on the **Safety** page. The rule evaluates only
a fresh, available Health estimate. It acts when `health < threshold`;
equality does not trigger it.

| Action      | Effect                                                                             |
| ----------- | ---------------------------------------------------------------------------------- |
| `none`      | Keep the session running and send the selected notifications.                      |
| `stop`      | Disconnect the session while retaining its linked credentials for a later restart. |
| `slow_down` | Cap outbound sending at the configured messages-per-second rate.                   |
| `log_out`   | Unlink the session. Pair it again before reconnecting.                             |

Unknown Health, stale evidence, or an unavailable estimator triggers no action.
The worker checks the latest Health again
before applying a queued action.

Read `GET /platform/bansafe/health-actions?projectId={projectId}` or open **Health
rule activity** on the Safety page to see queued actions and their durable
outcomes. Filter the API list by `session` or public `status`. Results are
newest first and cursor-paginated. A returned outcome is one of `applied`,
`cleared`, `notification_queued`, `superseded`, `expired`, `not_applied`, or
`delivery_failed`.

## Pacing rates

The `slow_down` action caps outbound sending at the messages-per-second value
saved on the project Health rule. The value must be positive and cannot exceed
the project's sending limit. Console and the API reject a higher value instead
of silently changing it.

Email and webhook delivery are optional. A webhook selection emits
`bansafe.health_threshold`; its stable action ID is also the webhook envelope
ID for retry deduplication.

## Existing operator controls

An operator control remains in force until it is changed or lifted. The Health
estimator cutover clears retired automatic ladder controls; it does not clear an
operator control and does not report a WhatsApp restriction change.

`GET /platform/bansafe/enforcement` reads controls and their application state.
`state: "applying"` means the control is stored but a connected runner has not
yet confirmed it. Polymorfa retries stored policy delivery.

## Provider restrictions

`bansafe.enforcement` reports an outcome observed from WhatsApp or one your
team reports. `bansafe.incident` reports the durable record and later
resolution. These events do not mean Polymorfa applied a Health-rule action.

A stopped or slowed session can continue to have a separately observed account
state. Console displays that observation with its own timestamp and source.

## Appeals and findings

A team owner, admin, or developer can appeal an existing Polymorfa restriction
with `POST /platform/bansafe/enforcement/{session}/appeal`. Acknowledge every open
finding first. An organization key or project token cannot make this statement
on a person's behalf.

Acknowledging a finding records who saw it. It does not change Health and does
not lift a restriction. Health changes after new evidence; restrictions change
when their own recovery conditions are met.

## Related

* [BanSafe Health](/guides/bansafe/overview)
* [Findings](/guides/bansafe/findings)
* [Safety in Console](/console/safety)
* [Webhooks](/api/webhooks#bansafe-events)