Submitted content is not retained. Operational metadata is.
Input text and returned analytical content are processed to produce the analysis and are not persisted by Sentiqra. Limited operational metadata - such as request ID, timestamp, API-key identifier, status, latency, and usage units - may be retained for security, billing, reliability, and audit purposes.
What is retained vs what is not
Sentiqra distinguishes content (your submitted text and the analytical signals returned to you) from operational metadata (data needed to run the service, bill accurately, and maintain security). Submitted content is processed in memory and not persisted; individual signal results are not stored outside the bounded exceptions below — the 24-hour idempotency replay record and webhook delivery payloads redacted within 7 days of terminal delivery. The response fingerprint is returned in the receipt and is never indexed or stored as a queryable operational field; its only server-side copy lives inside the bounded idempotency replay record when a key is supplied. Only aggregate counters and operational metadata are stored beyond that window. This policy covers the analysis API processing path; account details, support correspondence, billing records, and consented feedback are stored deliberately under separate retention schedules.
CONTENT - NOT RETAINED
- Input text
- Returned signals / analysis results*
- Raw request body
- Raw request headers
- Derived representations of submitted text (computed transiently during the request; not persisted)
OPERATIONAL METADATA - RETAINED
- Request ID
- Timestamp
- API-key identifier (hashed)
- HTTP status code
- Response latency (ms)
- Usage units (analyzer runs)
- Language code
- Connection identifier (observed source or upstream address, in security/request logs)
- Abuse-detection telemetry (keyed fingerprints of input, lengths, response metadata; ≤48h)
* Two bounded exceptions to "not retained", both disclosed in the retention schedule below: (1) when a request supplies an Idempotency-Key, the exact response (signals, operational metadata, and the verification receipt - never the submitted text) is held inside the idempotency record for up to 24 hours to serve identical replays, then deleted; (2) a webhook delivery you configure carries its signal payload until delivery completes, after which the payload is redacted within 7 days while the delivery record is kept.
The analysis fingerprint (fp2_…) and receipt are returned to you in each response and are not written to operational stores as queryable fields. Because the fingerprint is a deterministic digest of the result, an indexable stored copy would let anyone holding it test whether a request produced a common output - such as an empty result - so operational correlation uses the opaque request ID instead. The only server-side copy is the bounded exception above: the stored replay response inside an idempotency record (≤24 hours, only when you send an Idempotency-Key).
Scope: this section describes the analysis API processing path only. Data you deliberately create elsewhere - account details, support tickets and attachments, billing records, and consented classification feedback - is stored under its own retention schedule in the privacy policy.
The API contract never echoes your input text
When you send text to the /analyze endpoint, the response contains only signals and metadata. This is an observable property of the API contract - you can check it on every response.
{
"language": "en",
"language_source": "declared",
"signals": [
{
"analyzer": "trust-safety",
"code": "insults_derogation",
"label": "Insults & Derogation",
"score": 0.9,
"level": "category",
"confidence": "very_high"
},
{
"analyzer": "trust-safety",
"code": "insult",
"label": "Insult",
"score": 0.9,
"level": "label",
"parent": "insults_derogation",
"confidence": "very_high"
},
{
"analyzer": "trust-safety",
"code": "belittling",
"label": "Belittling",
"score": 0.9,
"level": "label",
"parent": "insults_derogation",
"confidence": "very_high"
}
],
"meta": {
"analyzers": [
{
"name": "trust-safety",
"status": "completed",
"applicability": "analyzable",
"assessment": "signals_detected",
"signal_count": 3,
"billed": true
}
]
},
"usage": {
"analyzer_runs": 1,
"billed": true
},
"verification": {
"version": 3,
"configuration": "sqcfg_ZZW77NM9",
"fingerprint": "fp2_8a72c4...19f",
"input_commitment": "ic3_31bd5e...a42",
"signature": "sig_ed25519_4c1f...e2a",
"key_id": "edk_af4f218e",
"binding_key_id": "bk_31bd5e42f7a019c8"
}
}
No "text" field. No "input" field. No "content" field. Note what this does and does not show: a response shape cannot prove internal storage behavior. Our non-retention commitment is enforced by processing controls - in-memory handling, the retention schedule below, and retention tests - not inferred from the response.
The request lifecycle
How submitted content is designed to be handled from the moment it arrives to the moment the response is sent:
Request arrives
Submitted text enters the API process in memory. It is parsed, validated, and held in a RAM buffer for the duration of the analysis call.
Analysis runs
Submitted content is processed in memory by the selected versioned analysis configuration. Processing does not create a persistent copy of submitted content.
Response assembled
Signals and metadata are serialized into JSON. The input text is not included in the response. The verification receipt - configuration ID, result fingerprint (fp2_…), input commitment (ic3_…), and Ed25519 signature (sig_ed25519_…) - is computed and returned in the response body's verification object.
Request completes
The in-memory copy of submitted text is discarded when processing completes, and the process moves to the next request. Operational metadata (request ID, timestamp, latency, usage units) is recorded under the retention schedule below. If an Idempotency-Key was supplied, the response - never the submitted text - is kept up to 24 hours for identical replays.
This describes designed behavior, not a proof you can observe from the response. The controls behind it - logging configuration, data-flow documentation, and automated retention tests - are part of the assurance evidence available through the Trust Center.
Operational metadata retention schedule
Submitted content is not persisted after the response completes. Operational metadata is retained according to the following schedule:
| Data class | Retention period | Purpose |
|---|---|---|
| Submitted content | Not retained | — |
| Signal-level results | Not retained | Not written to operational stores — the only copies are the bounded exceptions in this schedule: the 24-hour idempotency replay response and webhook delivery payloads you configure |
| Analysis result fingerprint | Not retained as a queryable field | Returned in the response receipt for your own verification — never indexed or stored as an operational field. A stored unkeyed result digest would allow candidate-output inference against common results. The only server-side copy is inside the bounded 24-hour idempotency replay record when you supply an Idempotency-Key (see that class); verification itself is a read-only recomputation. |
| Webhook delivery payloads | Until delivery ends, then ≤7 days | Delivered to customer-configured endpoints only; the derived-output payload (signals/indicators) is redacted after the delivery lifecycle while the delivery record is kept |
| Request & operational metadata | 30-90 days | Billing, abuse prevention, security, reliability, receipt verification. Per-request usage metadata is swept at 90 days; the security request-audit log is swept at 30 days. Longer windows may be agreed contractually |
| Abuse-detection telemetry | 48 hours | Anti-extraction & automated-abuse prevention. Non-content request fingerprints, response-code counters, connection signals - never submitted text |
| Idempotency records | 24 hours | Safe-retry deduplication. Holds the key, a keyed request hash, per-analyzer outcomes, and the stored response for identical replays - submitted text is never included |
| Aggregated analytics | 12 months | Usage analytics, Detection Insights, capacity planning |
| Audit events | 24 months | Security, compliance, investigations |
| Support tickets & correspondence | 24 months | Support history, dispute resolution, abuse investigation. Stored in the portal (not the analysis path) - keep secrets and customer-submitted text out of ticket bodies |
| Billing records & invoices | 7 years | Tax compliance (finance/legal) |
| Compute-metering metadata | 13 months | Per-run infrastructure cost metering (key id, analyzer, outcome, latency, configuration alias — never submitted content). Finance reconciliation and capacity planning |
Request metadata never includes submitted text or individual signal results — it is the operational envelope around the request: the fields needed to verify a receipt, reconcile usage, or investigate an incident. Retention bounds are the same on every plan: the request audit log is swept at 30 days and per-request usage metadata at 90 days. Longer metadata windows are agreed contractually (Enterprise) and recorded in the customer's agreement.
Retention periods are applied automatically - scheduled cleanup jobs run against each data class. Policies are versioned and auditable.