> ## Documentation Index > Fetch the complete documentation index at: https://docs.spritz.finance/llms.txt > Use this file to discover all available pages before exploring further. # Security > How the Spritz platform protects your integration and your users' data. Security is built into how the Spritz API works. This page summarizes the controls that are in place and how they show up in your integration. ## Authenticated, signed requests Every request is authenticated. Backend calls are signed with HMAC-SHA256 using your integrator key, a timestamp, and a signature, so Spritz can confirm a request genuinely came from you and wasn't altered in transit. Timestamps are checked against a 5-minute window to reject replayed requests. See [Authentication](/guides/authentication). ## Scoped, per-user access You act on behalf of a specific user with their scoped user API key. For client-side flows, you mint a short-lived, per-user token on your backend and hand it to the user's device, so a browser or mobile app can call Spritz directly without ever holding your backend credentials. ## Sensitive card data stays out of your servers Full card numbers, CVVs, and PINs are handled through encrypted, secure components and rendered client-side, so that sensitive card data never passes through your servers. See [Cards](/guides/use-cases/cards). ## Signed webhooks Webhook deliveries are signed. You verify the signature against the raw request body before trusting a payload, so you can be certain an event genuinely came from Spritz and wasn't tampered with. See [Webhooks](/guides/webhooks). ## Identity and monitoring Spritz runs identity verification (KYC), KYB, AML and sanctions screening, and transaction monitoring on the users moving money. Money-movement requests also pass risk checks before any funds move; a blocked ACH debit, for example, returns a `409` before the pull is initiated. See [Onboarding](/guides/onboarding) and [ACH returns](/guides/ach-returns). ## Encryption in transit All API traffic is served over HTTPS with TLS. ## Safe retries Idempotency keys ensure a retried request never moves money twice, even across network failures and timeouts. See [Idempotency](/guides/idempotency). ## Test safely Build and test against simulated rails using separate sandbox credentials before you touch real funds or real user data. See [Sandbox](/guides/sandbox). ## Compliance and due diligence For your security and compliance review, details on our compliance program, certifications, data handling, and banking and payment partners are available on request. Reach out and we'll share what's relevant to your review.