Zentra’s trust model is built around explicit boundaries: tenants, API keys, product enablement, webhook signatures, policy decisions, and audit evidence. This page explains what a technical evaluator should verify before treating Zentra as production financial infrastructure.Documentation Index
Fetch the complete documentation index at: https://docs.usezentra.com/llms.txt
Use this file to discover all available pages before exploring further.
Trust Surfaces
Tenant isolation
Requests, keys, enabled products, limits, webhook endpoints, and evidence are scoped to tenant context.
API key hygiene
Secret keys are server-side credentials. Live keys should be introduced only after sandbox behavior is proven.
Webhook signing
Webhook consumers must verify signatures before mutating state or notifying users.
Audit evidence
Operational records should preserve actor, tenant, timestamp, policy state, request identity, and outcome.
Evaluation Checklist
- Confirm sandbox keys and live keys are separated.
- Confirm tenant product enablement matches the namespaces your app calls.
- Verify idempotency behavior on money-affecting requests.
- Verify webhook signature handling and duplicate delivery behavior.
- Confirm support, finance, and compliance teams can inspect the same event trail.
- Keep draft or tenant-specific namespaces out of production paths unless explicitly enabled.
Responsibility Boundary
Zentra provides reviewed API contracts, tenant-scoped controls, signed webhooks, and operational evidence. Your application remains responsible for safe credential storage, secure webhook consumers, customer-facing state transitions, and internal authorization around who can trigger money movement.Use Reviewed Public Surface as the source of truth when deciding which namespaces are reviewed for default production integration.