Security at Orita

Every webhook delivery is signed with your endpoint secret using HMAC-SHA256. Verify the X-Orita-Signature header before processing. Invalid signatures must be rejected.

Each organization operates in a strict isolation boundary. An API key can only read, create, and modify resources belonging to its own organization. Cross-tenant access returns 404, not 403, to prevent resource enumeration.

The confirmation API requires explicit approval evidence before creating a booking. Calls without a valid approval response receive input_required, not a booking. This prevents accidental or unauthorized booking creation.

Confirmation endpoints enforce idempotency keys. Retrying the same confirmation with the same key returns the original booking without creating duplicates. Different keys with different bodies produce an idempotency conflict error.

Booking creation and outbox event persistence are committed in a single database transaction. If either fails, both roll back. No booking is created without a corresponding domain event.

The public Agent Card at /.well-known/agent-card.json is signed using ES256. External agents can verify the signature against the JWKS at /a2a/jwks.json before trusting the card.

Sandbox credentials cannot process live transactions. Any attempt returns 403 PRODUCTION_PLAN_REQUIRED. Test bookings always carry testMode: true and are excluded from billing and milestone detection.

Webhook secrets and API key secrets are stored as SHA-256 hashes — never in plaintext. The raw secret is shown once at creation and never again. Rotation invalidates the previous secret. No secrets appear in logs or API responses.