What the platform does on its side, and what an integration has to do on yours.
What we do
- Every request is over TLS 1.2 or 1.3 with HSTS; never send a key over plain HTTP.
- API keys are 256-bit random, shown once, and stored only as a SHA-256 hash. We cannot recover a key for you.
- Each key is bound to one programme; the programme is derived from the key, never from a parameter. Postgres row-level security sits underneath the application as a second wall.
- Webhook deliveries are signed with HMAC-SHA256 over a timestamp and the raw body; the secret is per endpoint and can be rotated (the old secret stops signing at once, so deploy the new one first and expect a few failed deliveries to be retried).
- Outbound webhooks never follow redirects, and endpoints on private or loopback addresses are refused when registered.
- Every request has an
X-Request-Id; quote it to support. - Errors never reveal whether a key exists, only that the request was not authorised.
What you must do
Keys. Keep them server-side. Never in a mobile app, a browser bundle, a public repository or a client-side config. One key per system, with only the scopes that system needs, so a leak is contained and revocable without breaking everything else. Revoke immediately on suspicion; rotation is for planned changes.
Browsers and apps. Use member session tokens. They are read-only, scoped to one member, expire in 15 minutes, and open only GET /v1/public/member.
Webhooks. Verify the signature before parsing the body — using the raw bytes, a constant-time compare, and rejecting timestamps more than 5 minutes old. Respond 2xx quickly and do the work asynchronously. See Webhooks.
Personal data. Members are identified by email, and optionally phone and your reference. If you enrol someone with POST /v1/members, send accepted_terms_version; without it we record no terms acceptance. Send us what the programme needs and no more; PATCH /v1/members/{id} records marketing consent so you do not have to keep a parallel record. When a customer asks to be forgotten, DELETE /v1/members/{id} erases them: direct identifiers are removed, and the ledger keeps its entries and totals with those identifiers removed. Their email and phone are also removed from stored API events, webhook deliveries, cached Idempotency-Key responses and the activity log.
Idempotency keys are not secrets, but they must be unguessable across customers if you derive them from ids a shopper can see — prefix them with something only your server knows.
Reporting a vulnerability
Email security@stickytier.com. We acknowledge within two working days and do not pursue researchers acting in good faith.