# Data retention

The events you send (your users' messages and actions) are the most sensitive
data SigWise holds. You choose how long they are kept, and you can delete
everything about an object at any time. Answers are kept whichever policy you
choose, so reads, rules and webhooks keep working.

## Choose a policy

Set it in the console under **Settings → Data retention**, or with the API:

| `event_retention` | Events are kept | Good for |
|---|---|---|
| `forever` (default) | Until you delete the object | Long-running scores such as trust built over months |
| `days` | `event_retention_days` (1 to 3650) after we receive them | A fixed limit from your own privacy policy |
| `after_analysis` | Until an analysis has read them, usually seconds. Requests with `"wait": true` are never written | Moderation where content must not be stored |

```bash
curl -X PATCH "$API/v1/settings?api_key=$SIGWISE_API_KEY" \
  -H "Authorization: Bearer $(sign)" -H 'Content-Type: application/json' \
  -d '{"event_retention":"days","event_retention_days":30}'
```

```json
{ "auto_backfill_signals": false, "event_retention": "days", "event_retention_days": 30 }
```

Changing back to `forever` or to another policy takes effect immediately for
new events. A stricter policy deletes stored events past the new limit within
the hour; deleted events can't be recovered.

## What analysis sees

Each analysis reads an object's recent events plus a **summary** of older
ones: how many messages and actions, broken down by action name.

- With `forever`, the summary also keeps a few example messages, so analyses
  have some of the older wording to go on.
- With `days` or `after_analysis`, the summary keeps **counts only**. Choosing
  either removes the example messages from every existing summary, since a
  summary outlives the events it was built from.
- With `after_analysis`, each analysis sees only the events sent since the
  previous one, plus those counts. That is usually enough to judge a message
  or a listing; for a score that depends on months of behaviour, prefer
  `days`.

## Sending events with `after_analysis`

Both ways of sending events work:

- **Asynchronous** (no `wait`): the events are stored, you get `202`, and they
  are deleted as soon as their analysis has read them. Webhooks and rules fire
  as usual.
- **Inline** (`"wait": true`): the events are scored in memory and never
  written. If the request fails (`402`, `503 analyzer_busy`, `502`), nothing
  was recorded, so **resend it**. A retry with the same `Idempotency-Key` is
  accepted.

Events that cannot be analyzed (for example while your balance is empty) are
deleted unanalyzed after 24 hours.

## Delete an object's data

When one of your users asks to be forgotten, delete everything stored about
them:

```bash
curl -X DELETE "$API/v1/objects/user-42?api_key=$SIGWISE_API_KEY" \
  -H "Authorization: Bearer $(sign)"
```

`204` means the object's events, answers, summary, queued analysis, rule
history and webhook deliveries are gone; `404` means nothing was stored for
that id. Billing records keep the object id they were charged for, as
financial records. The object reappears only if you send new events for it.
You can also delete an object from its page in the console, or by id under
**Settings → Data retention**.

## Other data

| Data | Kept |
|---|---|
| Answers | The latest per signal, until you delete the object |
| Webhook deliveries | 30 days |
| Rule firings and alert emails | 90 days |
| Billing records | Kept, as financial records |

To produce answers, the content of the events being analyzed is sent to our
AI model provider at analysis time. All traffic is encrypted in transit.