Security and incident response
Appease reads refunds. It cannot write to your store, and it does not keep your customers' data. Here is exactly how that is enforced, and what happens if something goes wrong. Last updated 4 August 2026.
What Appease can and cannot do
Appease holds two read-only Shopify scopes: read_orders and read_customers. It has no write access to any store and cannot create, alter or cancel an order, a refund or a customer record.
Every request from the embedded app is authenticated with a Shopify session token, verified server-side against the app's signing secret, with the audience, expiry and issuing shop all checked before anything is read.
Every webhook is verified against Shopify's HMAC signature. Unsigned or wrongly signed requests are rejected with 401 and nothing is processed.
Preventing data loss
Order-level data is never persisted. It is read from the Shopify Admin API at the moment an audit runs, held in memory to produce the result, and discarded. What remains is aggregate — counts and sums with no shopper identifier attached.
The database is hosted by Supabase in eu-central-1 with encryption at rest and encrypted automated daily backups.
Access tokens are stored encrypted and are short-lived: an access token expires after one hour and is refreshed automatically; the refresh token expires after 90 days. A token that leaks is useless within the hour.
Row-level security is enabled on every table. Application access uses a single service credential held only in the deployment environment, never in the repository.
Separating test and production data
Shopify development stores are identified at connection time through the shop's plan, and every record written from such a store is marked as test data.
Test records are excluded from production reporting, from any aggregate figure, and from the customer list used to run the business. They exist only so the app can be exercised end to end.
This means a development store can never contribute to a number a real merchant sees, and can never be mistaken for a paying customer.
Who can reach production
Access to the production database and deployment environment is limited to the two founders.
All accounts with access require multi-factor authentication and unique credentials held in a password manager. Credentials are never shared.
There are no shared or generic logins, and no third party has standing access.
Every read of protected customer data is logged: which store, when, what triggered it, and how many orders and refunds were read. The log holds counts only — an access log that itself contains personal data would defeat its own purpose.
If something goes wrong
1. Contain. Rotate the affected credential immediately — Shopify API secret, Supabase service key, or both — and revoke sessions.
2. Assess, within 24 hours. Determine which stores are affected, which data categories were exposed, and whether any shopper personal data was involved.
3. Notify. Affected merchants are told without undue delay and within 72 hours of us becoming aware, by email to the address on their account, with what happened, what data was involved, and what we have done. Shopify is notified in parallel where the incident concerns protected customer data.
4. Fix and write it up. The root cause is fixed, and a short written account is sent to affected merchants once the immediate work is done.
Report a suspected issue to henrik@appease.tech. Security reports are answered the same day.
Related: privacy · data processing agreement