Ingestion secrets are displayed once and stored as one-way hashes.
Security at Apirelio
A deliberately small data surface.
Apirelio is designed to answer who is using your API and where integrations are failing without becoming a store for request payloads or credentials.
Event IDs are deduplicated to prevent accidental double counting.
Oversized metadata and known sensitive keys are rejected.
Each ingestion key belongs to a single analytics project.
Controls that exist today
Concrete safeguards, described without security theatre.
We distinguish implemented controls from future compliance work. Apirelio does not currently claim SOC 2 or ISO 27001 certification.
Authentication and isolation
Dashboard access uses revocable bearer tokens. Email verification protects new workspaces, login and recovery endpoints are rate-limited, and every project query is authorized against organization membership.
Minimal collection
The Laravel, Symfony and Nette SDKs normalize route parameters and do not capture bodies, cookies, credentials, query strings or client IP addresses as analytics dimensions.
Safe ingestion
Project-scoped keys are hashed at rest. Events are validated, sensitive metadata keys are rejected, batches are bounded and ingestion is independently rate-limited.
Operational resilience
Production SDK delivery is queued and batched outside the customer request. Resolver, buffering and transport failures never modify the observed API response.
Retention and deletion
Projects have explicit retention settings. Account, privacy and deletion requests can be submitted directly to the Apirelio team through the contact channel.
Responsible disclosure
Security reports receive a dedicated topic and should include reproducible steps without exposing real customer data. We acknowledge valid reports and coordinate remediation.
Need a deeper review?
Bring us your security questionnaire.
We will answer based on the deployed environment and clearly identify controls that are planned rather than implemented.