Scoped API keys
Telemetry documents read, write, and read-and-write scopes. Use separate keys for ingestion, querying, and automation when responsibilities differ.
Queryable event storage
Telemetry checks incoming JSON against the table schema, buffers recent events for queries, and saves older events in compact Parquet files. DataFusion queries both.
Retention and deletion controls
Table APIs expose configurable retention, row deletion, and table deletion. Treat deletion as irreversible and restrict write-capable credentials.
Payment card data
Telemetry's privacy policy states that the payment processor receives payment card details directly. Telemetry does not store or collect those details.
Evidence map
Trace each public claim to its source
Use these references during an implementation review. For hosting regions, infrastructure vendors, subprocessors, certifications, penetration testing, or contractual commitments, request a current verified answer instead of inferring one from product documentation.
Log API and schema checks
Request shape, authentication, schema compatibility, and response behavior.
Storage and query architecture
The documented buffering, Parquet history, and DataFusion query path.
Retention and deletion
Table retention settings plus row and table deletion operations.
Exclude sensitive data
Practical redaction guidance for secrets, payloads, prompts, and personal data.
Published security controls
What we publish and what you need to verify
We checked this information against our public pages on July 30, 2026. If a control is listed as "Not publicly asserted", we have not claimed it here. It may still exist. Ask us for current evidence before making a procurement, compliance, or risk decision.
API authentication and scopes
Publicly documented
Read, write, and read-and-write key scopes are documented. This is an application control, not a claim about enterprise identity features.
Retention and deletion
Publicly documented
Table retention, row deletion, and whole-table deletion behavior are documented, including irreversible operations.
Hosting and data location
Policy statement; reconfirm
The privacy policy names AWS and United States processing. It does not provide a current region list or customer-selectable residency commitment.
Payment processing
Policy statement
The privacy policy names Stripe and states that payment-card details go directly to the processor rather than being stored by Telemetry.
Encryption, key management, and tenant isolation
Not publicly asserted
The public pages reviewed do not specify encryption-at-rest design, key ownership or rotation, or the technical tenant-isolation model.
Backups, recovery, and availability commitments
Not publicly asserted
The public pages reviewed do not specify backup frequency, restore testing, recovery objectives, uptime commitments, or a disaster-recovery architecture.
Independent assurance and testing
Not publicly asserted
No public SOC 2, ISO 27001, penetration-test, vulnerability-disclosure, or audit-report claim is made on this page.
Subprocessors and contractual privacy terms
Request current documents
The privacy policy names some service providers, but it is not presented as a current subprocessor register, DPA, SCC package, or complete vendor inventory.
Enterprise access controls
Not publicly asserted
No public claim is made here for SAML SSO, SCIM, configurable RBAC, audit-log immutability, IP allowlists, or customer-managed keys.
Before sending events
Data to keep out by default
- Passwords, API keys, auth headers, cookies, and session tokens
- Private keys, wallet mnemonics, signatures, and credentials
- Raw prompts, completions, webhook bodies, and job payloads unless specifically reviewed
- Payment-card data and unnecessary personal or customer content
Safer event design
Prefer categories and identifiers
- Record error_type and failed_step instead of a raw sensitive payload
- Use route templates rather than URLs containing identifiers
- Store accepted, saved, retried, or discarded outcomes without raw AI content
- Keep environments, services, owners, and stable event names consistent
Before we publish a security claim
What we need to verify a control
We check the evidence and approve the exact wording before publishing a security claim. A questionnaire answer or roadmap item alone is not enough. Each claim must pass these checks.
- Control owner and approval of the exact public language
- Current primary evidence with a review date and expiration or revalidation date
- In-scope services, environments, data, tenants, regions, and exceptions
- Implementation and operating evidence rather than a roadmap statement
- Contractual or policy boundary when the public summary is not a commitment
The record is an intake and review tool. Completing it does not make a claim public or convert private evidence into a contractual commitment.
Public documentation and policy
This page is a product overview, not a contractual security addendum. The privacy policy and terms govern their respective subjects; contact Telemetry for current answers to requirements not covered publicly.