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, stored as a keyed 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. 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} anonymises them and their ledger keeps its totals with no identity attached.
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.