Security overview
Current controls and roadmap for event-driven gamification.
Hatched keeps server credentials out of the browser, scopes widget access through short-lived tokens, separates customer configuration from public widget surfaces, and publishes its security roadmap without claiming certifications before they are complete.
Last updated June 14, 2026
Current controls
The current security model is intentionally narrow: Hatched processes product events, progression configuration, widget state, operational metadata, and billing/support data needed to provide the service.
- Every API request is authenticated with a server-side secret, dashboard JWT, scoped widget token, or scoped publishable key.
- Request IDs, event IDs, and webhook delivery IDs are retained for support correlation and incident review.
- Dashboard account changes, password resets, admin password sets, and impersonation boundaries are handled through explicit authenticated flows.
API and widget boundaries
Production integrations use server-side API keys for privileged operations. Browser widgets use scoped tokens minted by the customer application, so public clients do not need long-lived credentials.
- API keys can be created and rotated from the dashboard.
- Widget session tokens are intended to be short-lived.
- Embed/session scopes limit what each widget surface can do.
Data handling
Hatched stores customer workspace configuration, registered event types, accepted event payloads, widget state, and operational metadata needed to provide the service.
- Customers control which product events they send.
- External user identifiers should be stable application IDs, not unnecessary personal data.
- Legal review can route through the DPA page for production data processing.
Monitoring and incident response
Operational surfaces expose health checks, public status updates, webhook delivery health, request correlation, and customer-facing support paths.
- Webhook health reports track active endpoints, success rate, recent failures, retries, and daily digest notifications.
- Status updates should include affected surface, start time, mitigation, resolution, and follow-up action.
- Support reports should include workspace ID, request ID, event ID, affected endpoint, reproduction steps, and impact.
SOC 2 roadmap
Hatched is not publishing a SOC 2 certification claim on this page. The roadmap is to keep current controls documented, close audit evidence gaps, run an external readiness review, complete remediation, and then pursue a formal audit when production scope justifies it.
- Near term: access control inventory, change-management evidence, incident runbooks, vendor/subprocessor register, backup and retention notes.
- Readiness: external security questionnaire support and customer-specific evidence review during enterprise procurement.
- Certification: publish only completed audit status and dates once an independent audit is finished.
Security review and contact
Security reports and procurement reviews should include affected workspace, endpoint, reproduction steps, impact, expected timeline, and any questionnaire or deadline.