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.

Data retention ​

Choose a policy ​

What analysis sees ​

Sending events with after_analysis ​

Delete an object's data ​

Other data ​