This feature is only available for Enterprise accounts
The Snappy APIs are inherently secure and built to meet modern enterprise compliance standards (including SOC2 and ISO). In addition to standard API security best practices, Snappy protects your data and integrations through two advanced security mechanisms: Granular API Permissions and Mutual TLS (MTLS).
1. Granular API Permissions (Scoped Keys)
Available to all accounts
To enforce the Principle of Least Privilege, Snappy allows administrators to create highly specific, scoped API keys. Instead of issuing a single "Master Key" that has full access to your entire account, you can restrict exactly what each key is allowed to do.
Targeted Access: Keys can be limited to specific actions (e.g., "Read Only" vs. "Full Access") or restricted to specific sub-accounts. If an integration only needs to read gift statuses, it will be blocked from sending gifts or spending budgets.
Sensitive Data Protection: By default, API responses mask Personally Identifiable Information (PII) such as employee names, emails, and phone numbers. Users must actively explicitly opt-in to expose sensitive information when generating a key.
These permissions minimize the "blast radius" in the event that an API key is ever leaked or mishandled by a third-party application, ensuring your data remains safe.
2. Mutual TLS (MTLS)
This feature is only available for Enterprise accounts
For integrations requiring the highest level of network security, Snappy offers MTLS.
MTLS stands for "Mutual TLS" (Transport Layer Security) and refers to a security mechanism used to secure communication between a client and a server in the context of an API (Application Programming Interface).
TLS is the successor to SSL (Secure Socket Layer) and provides a secure, encrypted communication channel between two parties over a network. In the case of an API, the client is typically a user, application, or service that wants to interact with the API, and the server is the backend that hosts the API.
In the traditional TLS/SSL setup, the server is authenticated to the client using an SSL certificate, which contains the server's public key. This allows the client to verify the server's identity. However, the client is not always authenticated in this scenario, meaning the server cannot be sure of the client's identity.
MTLS extends the security of TLS by requiring mutual authentication between both the client and the server. In MTLS, both the client and the server present their respective SSL certificates to each other to verify their identities. This means that not only the server authenticates itself to the client, but the client also authenticates itself to the server. The process of MTLS can be summarized as follows:
The client initiates a connection to the server.
The server presents its SSL certificate to the client for authentication.
The client verifies the server's identity using the SSL certificate.
The client also presents its SSL certificate to the server for authentication.
The server verifies the client's identity using the client's SSL certificate.
Once the mutual authentication is successful, the communication channel is established with a high level of confidence in the identities of both the client and the server. This is particularly useful in scenarios where strict security is required, such as financial transactions, sensitive data exchange, or in microservices architectures where different services need to trust each other before exchanging data.
Implementing MTLS for an API enhances security and helps prevent man-in-the-middle attacks, where an attacker intercepts and impersonates either the client or the server to gain unauthorized access or steal sensitive information.