# Service Level Agreement — Target Commitments

This document describes Guild's availability, durability, and incident-response posture for the v1 launch.

## Availability targets

These are targets, not contractual commitments in v1. As the portfolio scales, we will move to formal contractual SLAs per tenant.

| Surface | Target availability | Rolling window |
|---|---|---|
| `POST /v1/users/link` | 99.9% | 30 days |
| `POST /v1/transactions` | 99.9% | 30 days |
| `GET /v1/wallet/:tenant_user_id` | 99.9% | 30 days |
| Hosted `/join`, `/login`, `/wallet` pages | 99.9% | 30 days |
| Operator ops console (`/ops/*`) | 99.5% | 30 days |
| Daily settlement workflow | Complete within 6h of 00:00 UTC | Every day |
| Monthly WORM snapshot export | Complete within 24h of month close | Every month |

**Availability definition:** percentage of minutes in the window where the endpoint returns 2xx for synthetic probe requests and does not error on valid requests.

**Explicit non-commitments:**

- Third-party dependencies (Stripe, Stytch, Neo4j Aura, immudb, Temporal Cloud) — Guild availability is bounded above by the availability of these services. We build for graceful degradation but cannot exceed their uptime.
- SMS delivery latency — Stytch-dependent, often carrier-dependent. Not measured by Guild SLA.
- Temporal workflow execution latency — commercially reasonable, not guaranteed.

## Data durability

- **Immudb** is the source of truth for all trust-sensitive events (transactions, settlements, reversals, billing events). Cryptographic append-only log with tamper-evident state hash.
- **Postgres + Neo4j** are projections of immudb. Can be rebuilt from immudb if lost.
- **Monthly WORM snapshots** are exported to an Object-Lock bucket with a 7-year retention policy.
- **Point-in-time recovery** for Postgres with 7-day retention.
- **RPO (Recovery Point Objective):** 5 minutes for Postgres; zero for immudb (append-only).
- **RTO (Recovery Time Objective):** 4 hours for full service restore in v1 posture.

## Incident response

### Severity levels

| Severity | Example | Target response | Target mitigation |
|---|---|---|---|
| SEV-1 | Core API (`/v1/transactions`) is down for all tenants | 15 min ack | 2 hours |
| SEV-2 | Single-tenant bug, wallet misrepresenting balance | 1 hour ack | 8 hours |
| SEV-3 | Hosted page rendering issue, non-blocking | 24 hours | 5 business days |
| SEV-4 | Doc bug, cosmetic issue | 3 business days | Next release |

### How to reach us

- **Urgent (SEV-1, SEV-2):** `incidents@guildapi.dev`
- **Non-urgent:** `support@guildapi.dev`
- **Security issue:** `security@guildapi.dev` — please do not file publicly

Provide your tenant slug, the endpoint affected, and a UTC timestamp when describing an incident.

### Status page

A formal status page is planned. Until it ships, Guild ops will email affected tenants directly on any incident that affects external availability.

## Change management

### Deployment windows

- Routine deploys: any time; no scheduled downtime
- High-risk changes (schema migrations, idempotency changes, settlement algorithm changes): deployed during low-traffic windows with advance notification to affected tenants

### Breaking changes

We do not ship breaking API changes to `/v1/*` endpoints. New capabilities ship as additive fields on existing endpoints or as new endpoints.

If a breaking change becomes necessary, we will:

1. Announce minimum 30 days in advance via direct email to all tenants
2. Ship `/v2/*` in parallel
3. Provide a migration guide
4. Support `/v1/*` for minimum 12 months after `/v2/*` ships

### Deprecation policy

Deprecated endpoints continue to work for at least **12 months** after the deprecation announcement. Deprecation is communicated in:

- Release notes
- Response headers (`X-Guild-Deprecated: true`) on affected endpoints
- Direct email to tenants currently calling the endpoint

## Your obligations

For Guild to meet its SLA targets on your tenant:

- Keep your API key current and rotated on your cadence
- Keep your Stripe payment method current for protocol fee invoicing
- Respond to Guild's security and compliance notifications within 5 business days
- Report incidents via the channels above, not via social media or public forums (we respond faster privately)
- Do not exceed published rate limits (see [Marketplace Onboarding Guide](../onboarding/marketplace-onboarding.md#rate-limits))

## SLA credit policy

No financial SLA credits in v1. If Guild fails to meet a target for a rolling 30-day period affecting your tenant, we will acknowledge the miss in writing and, where applicable, prorate any protocol fees billed for the affected period.

## Changes to this document

Material changes to this SLA are communicated via the Marketplace Operator channel with at least 30 days notice. This document is the canonical reference — do not rely on verbal commitments that contradict it.

---

*Last updated: 2026-04-16.*