Skip to main content

Reliability & Resilience

Permissio does not offer a contractual Service Level Agreement. Availability is best-effort. Incidents are handled promptly and communicated through the partner contact channel and, when available, a status page.

For most production integration patterns, best-effort availability does not translate to unreliable service delivery. The queue-based resilience model below explains why.

Availability​

Permissio provides Services on a best-effort basis and does not commit to a specific uptime percentage or offer service credits for availability failures. Partners that require contractual SLA commitments should contact the partner team to discuss their requirements.

Queue-Based Resilience Model​

Permissio is designed so that a transient outage does not cause data loss or missed events, provided both sides follow a queue-based integration pattern.

Server side:

  • All envelope state is stored in PostgreSQL with ACID guarantees. A 201 Created response means the row is committed.
  • Outbound webhook deliveries are managed by a transactional job queue. Webhook dispatch is enqueued atomically with the triggering event, so a process restart never silently drops a delivery.
  • Webhook delivery retries with exponential back-off for approximately 27 hours before the delivery is marked failed and moved to a dead-letter queue. Failed deliveries appear in the webhook replay console and can be retried manually.

Recommended client pattern:

  • Use a transactional outbox on your side: write the intended action to your own database before calling the Permissio API. If the call fails or times out, your outbox processor retries it. Combined with Permissio's idempotency-key support, this makes duplicate deliveries safe.
  • Subscribe to webhook events for state changes rather than polling. If a webhook delivery is missed, use GET /v1/envelopes with the updated_since filter to reconcile.
  • Use GET /v1/envelopes/:id to confirm final state before releasing resources. Never rely solely on a webhook that may have been delayed.

With both sides following this pattern, a Permissio outage of any duration is survivable with zero data loss.

Webhook Reliability​

All outbound webhooks are:

  • Signed. Every delivery includes an X-Permissio-Signature HMAC-SHA256 header so you can verify authenticity.
  • Retried. Failed deliveries are retried with exponential back-off for approximately 27 hours.
  • Replayable. Any delivery can be re-triggered from the webhook replay console for up to 30 days.
  • Auto-disabled. An endpoint that fails 6 consecutive deliveries is automatically disabled to prevent noise. It can be re-enabled from the console once the issue is resolved.

Incident Communication​

When an incident affects service availability:

  1. The partner contact channel is notified.
  2. A status update is posted to the status page when available.
  3. A post-incident summary is provided for significant incidents on request.

Permissio does not commit to specific incident response time targets.

Status Page​

A live status page with historical uptime data is on the roadmap. A link will appear here when it is available.