Security and Operational Controls
Most security pages are designed to reassure you. This one is designed to be accurate. It describes the controls we can support with repository evidence today, and it stays narrower than a marketing-style security page because accuracy matters more than theater.
Audit logging
The platform includes audit and event records so operational changes are easier to trace and review.
Idempotent booking operations
Booking flows support idempotency keys so repeated requests can be handled more safely.
Signed webhooks and retries
Webhook deliveries include signing and retry behavior instead of relying on best-effort fire-and-forget delivery.
Validation and tenant-aware boundaries
The codebase uses validation and tenant-scoped patterns across the booking workflow, widget surfaces, and agent integrations.
Database-backed booking state
The booking workflow keeps its own booking records instead of treating an external calendar as the only source of state.
Background delivery for side effects
Email and webhook-style work is structured so the booking flow is not coupled to a single inline side-effect path.
What We Describe Publicly
- Booking and availability routes are implemented.
- Webhook deliveries include HMAC signing and retries.
- Booking flows support idempotency keys.
- Audit and event logging exist in the codebase.
- Operational status endpoints and background workers are part of the system.
What We Do Not Claim Here
- No public compliance certification claim is made on this page.
- No uptime guarantee or SLA is posted here.
- No specific encryption standard is claimed here without deployment evidence.
- No penetration-testing or audit-program claim is made here without formal proof.
Need a Deeper Review?
If your team needs a questionnaire, architecture conversation, or a more detailed review of the implemented controls, contact us directly. We would rather answer narrowly and accurately than overstate what is already packaged publicly.