Privacy Policy

Stabile Rewards Wallet and Stabile: Loyalty Rewards Agent — ChatGPT plugins & MCP Server
Developer: StabileRewards • Effective Date: 2026-11-01 • Contact: privacy@stabilerewards.com

This Privacy Policy describes how Stabile Rewards Wallet and Stabile: Loyalty Rewards Agent (“we”, “our”, or “us”) handles data when shoppers, merchants, and AI agents invoke our tools via our ChatGPT plugins and MCP (Model Context Protocol) server. We are committed to full transparency about the data categories our tools receive, return, and log for service operation, security, and support.

Shoppers can use Stabile through a reward wallet (section 1.5) and through the following store-specific flows: by signing in with a participating store’s own customer account (section 1.1), by asking about a store’s reward terms without signing in (section 1.2), and by requesting a store that doesn’t use Stabile yet (section 1.3). Some other MCP connections to our server, used by other AI assistants and integrations, accept an email address or customer ID instead of a sign-in (section 1.4).

1. Data We Process

1.1 Signed-in reward checks (“Check my reward”)

When you connect the app, you choose a participating store and sign in on that store’s own website with its customer account, then approve “Check my reward”. We never see your store password. You can instead choose the shared test account, a test shopper used for trying the app and for app review; it contains no personal data and its test points are shared by everyone who chooses it.

Data	Source and purpose	Returned to the AI assistant?
Shopify customer ID at the chosen store	Provided by the store through Shopify after you sign in. Used to find your rewards at that store. Stored with a pseudonymous identifier for this connection; we do not receive your password.	No
Your approval (consent record)	What you approved, when, for which store and AI assistant, and whether you later disconnected.	No
Access and refresh tokens	Issued to the AI assistant after you approve. Access tokens last 5 minutes; refresh tokens up to 30 days. We store only hashes of refresh tokens.	Held by the AI assistant, not shown in responses.
Reward values you can use	Calculated from your loyalty balance and the store’s program, optionally for a cart subtotal you give.	Yes: reward values, currency, and how many unused codes you hold. Not your points balance.
Your unused reward codes	Only when you approved sharing codes. Read from the store; never created or spent by the app.	Yes: each code, its value, currency, expiry, and whether it works only while signed in to your store account.
Store domain and store link	Identifies which store the rewards belong to.	Yes.

Signed-in checks never return your email address, name, orders, or points balance, and they cannot create codes, spend points, or apply discounts. While a store’s pilot runs, we record your approval and each reward check to measure the pilot. These records are linked to the pseudonymous identifier and include the outcome and, when applicable, the cart subtotal you supplied, currency, maximum eligible reward value, and number of unused codes. We do not store the codes themselves in pilot measurement records. You can disconnect at any time on the store’s “Check my reward” page, which stops further checks immediately; removing the app in your AI assistant also stops it from checking.

1.2 Store reward terms without signing in

You or your AI assistant can ask about a store’s reward program without signing in. The request contains only the store’s name, website, or Shopify domain and a cart subtotal; it never includes your email, customer ID, or other identity. We return the store’s public program terms (earn rate, minimum spend, first-order bonus, reward tiers) and what that cart would earn, but only for stores that chose to make their program visible to AI assistants. If a store isn’t available, we return a link to request it (section 1.3). We log the store as given and the outcome to learn which stores shoppers ask about.

1.3 Store requests (“Don’t see your store?”)

If you request a store that doesn’t use Stabile yet, we receive the store name or website you enter and, only if you choose to give it, your email address. We use the request to ask the store to join and, if you gave an email, to tell you when it does. We save the request and use Resend to send a notification, including any email you gave, to our team; the request remains saved if email delivery is unavailable. We don’t store your network address with the request; we keep only a keyed one-way hash of it, to limit repeated requests.

1.4 Email-based tools on other connections

Some connections to our MCP server, used by other AI assistants and integrations, identify a shopper by an email address or customer ID supplied in the request instead of a store sign-in. The table below lists the input fields accepted by those tools, their purpose, and whether the same field or a derived value may be returned in a response.

Field	Category	Purpose	Returned in response?
`customer_email`	Buyer identifier	Identifies the buyer with shopper consent so rewards can be looked up, redeemed, or issued to the correct account.	The full email is not returned. Masked email may be returned for win-back customers.
`customer_id`	Buyer identifier	Shopify customer identifier or GID used when a direct customer id is available instead of an email address.	No
`customer_key`	Buyer identifier	Opaque customer key returned by the win-back context tool and used to issue a reward to an eligible configured customer.	Yes, when needed to confirm the selected win-back customer.
`cart_total`	Transaction data	Current cart value in USD. Used to calculate eligible reward options and their economic impact.	May be returned in nested cart outcome fields such as cart total before or after a reward.
`cart_id`	Session identifier	Merchant-provided checkout session ID. Used to correlate reward actions to a specific cart. Not returned in tool responses.	No
`transaction_id`	Transaction reference	Merchant’s reference ID for the underlying commerce transaction. Associates reward issuances with the correct order.	Yes. We may return the normalized value recorded for auditability.
`reward_amount`	Reward data	Quantity of loyalty points to be issued for a permitted win-back reward.	Yes.
`idempotency_key`	Technical identifier	Caller-generated key used to safely deduplicate retried redemption or issuance requests.	Yes. We may return a derived hash value used for deduplication.
`shop_domain`	Merchant identifier	Shopify merchant domain used to route requests to the correct connected store.	Yes.
`option_id`	Reward selection	Reward option selected from the options returned for a cart.	Yes.
`unit`	Reward unit	Unit label supplied for a win-back issuance. The current tool accepts points only.	Yes, as a normalized unit value. The raw value may be recorded in audit logs.
`reason`	Reward reason	Required fixed reason for permitted win-back issuances.	May be returned in customer eligibility context.
`force_new`	Reward instruction	Indicates whether the shopper explicitly asked to create a new reward code even if an unused equal-or-better code already exists.	No

Tool responses may include these categories

Reward codes and redemption status, including a discount code, expiration time, replay status, whether an existing reward was reused, and explanatory text.
Reward option details, including option identifiers, reward type, value, value amount, points required, eligibility, and explanation.
Nested cart and reward economics, including discount amount, cart total before and after a reward, points spent, points held, points available, projected points earned, points earned if redeemed or not redeemed, points delta, estimated point value, net value, and whether a reward drops the cart below a minimum spend.
Balance and tier information, including whether the balance is known, points balance, points before and after an issuance, next tier, points needed, tiers, earn rate, minimum spend, and first-order bonus assumptions.
Customer and win-back context, including opaque customer keys, display names, masked email addresses, eligibility reason, eligible customers, and allowed point amounts.
Merchant and store context, including shop domain, store key, display name, store URL, app URL, connection status, and whether the store is connected.
Technical and debug fields, including request status, replay flags, normalized transaction identifiers, derived idempotency keys, Shopify balance sync status, resolved routing method, and customer-known flags.

Service logs may include these categories

Tool names, JSON-RPC request ids, request status, duration, session ids, timestamps, and error codes.
Request parameters needed for auditability and support, with known email fields redacted before logging.
Authentication verdicts, authentication carrier labels, request paths with path secrets redacted, IP address, and user agent for security monitoring.
Metadata the AI platform attaches to a request. Until 2026-10-08, audit records kept this metadata as received, such as the client’s browser user agent, locale, and approximate location (city, region, country) when the platform provided it. Since then we keep only the fields described in the next four items; older records age out under the retention schedule in section 3.
Keyed hashes of AI-assistant identifiers. We do not keep the raw account, session, or organization identifiers an AI assistant attaches to requests. We keep keyed hashes (HMAC-SHA-256 with a secret held only by us) of them, including on requests that need no store sign-in, so we can tell our own testing from other usage and count returning accounts. A hash cannot be recomputed without our secret.
A broad client surface and locale. A coarse category derived from the client’s user agent (web, iOS app, Android app, or unknown), plus the platform’s locale and time zone. We do not keep the client’s own browser or device user agent, platform correlation identifiers, or approximate location in these records.
Short, redacted tool arguments. For connection checks, the message the AI assistant wrote (up to 300 characters); for store lookups, the store name or domain as given (up to 120 characters); whether a customer identity was supplied (yes or no, never the identity); and the cart subtotal when given. Email addresses, phone numbers, bearer tokens, and path secrets are removed before storage. We do not receive or store the original conversation between you and your AI assistant.
A request category. A label for each request, such as our own testing, an automated scanner or reviewer, or other usage.
For store reward terms without sign-in: the store as given, the outcome, and the time.
For signed-in checks: authorization events (requested, approved, denied, refreshed, disconnected) with the store, AI assistant, scopes, and a hash of the pseudonymous identifier; never tokens, codes in plain text, or passwords.
Pilot measurement records: the store, AI assistant, event, outcome, and pseudonymous identifier hash, with the supplied cart subtotal, currency, maximum eligible reward value, or unused-code count when applicable.
Win-back issuance audit entries, including shop domain, customer key when used, reward amount, normalized unit, raw unit label, transaction id, normalized transaction id, replay status, and Shopify balance sync status.

1.5 Reward wallet

In Stabile: Loyalty Rewards Agent, the reward wallet saves rewards across stores you have linked. That wallet is associated with the connected app: we never see your OpenAI login; we derive and store a pseudonymous owner key using HMAC-SHA-256 of the identifier OpenAI supplies to the app and a server-held secret. Access after removing, reinstalling or replacing the app is not guaranteed, and wallets should not be assumed to be shared between apps. To unlink a store or delete your wallet, use the wallet management controls while you still have access.

We keep links between that key, each store and its Shopify customer account, how each link was verified, timestamps, and pointers to saved rewards and Shopify discounts. These are pseudonymous personal-data linkages. We also keep hashed claim proofs, claim expiry and consumption state, hashed web-verification proofs and attempt counts, delivery-job state, and security records needed to prevent replay. We do not store your email address in wallet tables.

Saving a reward links that store account, so later rewards can appear automatically while that store enables wallet delivery. Every other store needs its own verification; a shared email address does not authorize another store. Delivery jobs operate independently of reward email. Reward status, expiry and conditions are checked against store records; failed checks are shown as unknown.

To link a store by email, enter your address and the emailed code on our Stabile web page. We look up the address in the store’s Shopify records and send through Resend. The verification email has no links. Do not paste its code into a chat. The provider processes the destination and message content under the email disclosure in section 3.

Your controls. Ask for your wallet management link to unlink a store or delete your wallet. Unlinking stops future delivery from that store and removes its visible entries. Deleting removes wallet links, entries, web challenges and request/action records, invalidates old management links, and lets the next unused reward claim start a fresh wallet. It does not reactivate consumed claim links or delete the store’s reward codes, order records, separately retained logs or delivery history. Small replay markers remain temporarily; consumed claims have their wallet-owner reference cleared.

Wallet record	Expiry and cleanup
Verification codes and challenges	Codes expire after 10 minutes and allow at most five attempts. Challenges become eligible for cleanup one day after expiry or consumption.
Claim links and use markers	Claims expire after 30 days or at reward expiry, whichever is first. Unused expired claims become eligible for cleanup then; consumed claims remain until 90 days after claim expiry.
Entries and store links	Entries become eligible 90 days after removal, reward expiry or redemption; revoked links after 90 days. Active links remain until unlinked or deleted. Explicit wallet deletion removes its links and entries immediately.
Deleted-owner and spent-write markers	Deleted-owner markers become eligible 90 days after deletion. New spent-write markers expire 90 days after their claim expiry, or after wallet deletion when deletion updates that marker. Legacy spent markers without a recoverable age expire 120 days after the W4.5 migration.
Requests, management actions and delivery jobs	Write-request and consumed management-action records become eligible after 31 days; delivered, skipped or failed delivery jobs after 90 days. Nonces and rate-limit buckets have shorter security cleanup windows.

Cleanup runs in bounded daily batches when retention is enabled; records may wait for a later batch. We log aggregate cleanup counts. Merchant issuance records and synthetic reviewer inventory have their own operational retention and are not erased by deleting a wallet.

Wallet telemetry. Tool-usage records include tool names, outcomes, timing, request/client information, IP address, service user agent, keyed hashes of account/session/organization identifiers, locale/time zone and bounded redacted tool arguments as described elsewhere in this policy. Wallet flags record whether owner identity was available and whether a call used linked context; they are not always a count of active links. These audit events exclude the wallet owner key, claim and verification codes, and private management links. We do not receive the full conversation. Rolling Redis audit lists last up to seven days and daily lists up to 90 days by default, unless configured differently.

Hosting request logs. Request addresses may briefly contain claim or management-link tokens in our hosting provider’s short-lived log buffer. We restrict access to the account owner and do not export those logs to drains or logging add-ons. Application and MCP audit logs redact these capabilities. Moving capabilities out of URL paths is planned for a later update; we do not claim the hosting router itself redacts them.

2. How We Use This Data

Data is used exclusively to:

Read merchant loyalty program terms and calculate projected points for a cart.
Link your store customer account to your AI assistant after you sign in and approve, and show your reward values and unused reward codes.
Measure participating stores’ pilots in aggregate, and record which stores shoppers ask for.
Handle store requests: ask the requested store to join and, if you gave an email, tell you when it does.
Look up shopper balances, unused reward codes, and eligible reward options when the shopper provides or authorizes an identifier.
Redeem a chosen reward option and return a discount code before checkout.
Issue permitted win-back loyalty points to an eligible configured customer.
Deduplicate retried requests via idempotency key.
Understand how the service is used, in aggregate: tell our own testing from other usage, count returning AI-assistant accounts using the keyed hashes described in section 1, and see which stores and kinds of requests assistants make, so we can improve the service. We do not build profiles of individuals and do not use these records to identify you.
Operate, secure, debug, and audit the MCP service.

We do not use any data for advertising, profiling, model training, or any purpose beyond delivering the loyalty reward service.

3. Data Retention

Tool requests are processed at request time. We do not create a general buyer profile in the MCP server. The merchant loyalty system may retain reward, balance, redemption, and issuance records as needed to operate the merchant’s loyalty program.

For service reliability, security, and support, the MCP server writes audit events to infrastructure logs and, when configured, Redis. The rolling Redis event list is retained for up to 7 days. Daily audit lists, including store reward-terms lookups and the keyed hashes and redacted tool arguments described in section 1, are retained for up to 90 days by default, unless configured differently. Session state required for SSE transport is held in Redis and scoped to the active connection.

For signed-in reward checks and store requests:

Store account link and approval: valid for up to 90 days unless you disconnect sooner; deleted 30 days after it expires or is disconnected.
Sign-in requests, authorization codes, and authorization audit events: deleted after about 7 days.
Refresh tokens (stored as hashes): last up to 30 days; deleted 7 days after they expire or are used.
Pilot measurement events: deleted after 180 days.
Store requests in our application database, including any email you gave and the network-address hash: removed by daily retention cleanup after 180 days.

Email notifications and related correspondence are separate from the application database record. Resend documents 30-day email and log retention on its Free, Pro, and Scale plans; Enterprise retention can differ, and its backups persist for 7 days. See Resend’s retention information. Messages already delivered to our team’s inbox are not automatically deleted by the application’s 180-day database cleanup. We retain correspondence as needed to handle your request, follow up about the store, and respond to support or privacy inquiries. You can request deletion of these copies by contacting us.

When a store uninstalls Stabile or asks us to delete a customer’s data through Shopify, we delete the related links, approvals, and measurement records.

4. Data Sharing and Disclosure

We do not sell buyer or merchant data. We may share data only in these limited situations:

Connected merchant systems — Shopify merchant loyalty APIs and related StabileRewards merchant services used to read balances, redeem reward codes, and issue points.
The AI assistant you use — tool responses described above are returned to the AI assistant that called the tool (for example ChatGPT), and are handled under that assistant provider’s own privacy policy.
Participating stores — aggregate pilot results (for example, how many shoppers connected or checked rewards), not your email or name. When you ask us to, we contact a store you requested; we do not give it your email.
Email delivery provider — store requests are sent to our team through our email provider.
Infrastructure providers — hosting, logging, and Redis session or audit storage, under strict confidentiality agreements.
Legal requirements — when required by law, regulation, or valid legal process.
Business transfer — in connection with a merger or acquisition, with appropriate notice to affected parties.

5. Data Security

All data is transmitted over TLS-encrypted connections. Access to infrastructure is restricted to authorized personnel. We apply industry-standard access controls and secure communication protocols throughout our stack.

6. Your Rights

Stabile Rewards Wallet: Stabile account and reward wallet

When you sign in to Stabile Rewards Wallet, we send your email address to Resend to deliver a one-time sign-in code. We store a keyed, one-way representation of your email to recognize your Stabile account when you return. We store sign-in code proofs as keyed hashes and use short-lived attempt records to protect sign-in.

Your wallet uses a pseudonymous key derived from your Stabile account ID. We store which stores you link, their store customer identifiers, how the links were verified, and references to saved rewards and store discounts. We use this information to show available rewards and existing unused codes and to estimate prices after saved rewards. You can link a store by claiming a reward or verifying your store account. Checkout stays with the store.

Ask for your private wallet management link to unlink a store or delete your Stabile account and wallet. To delete the account, choose the delete action and confirm it on the next page. Deletion removes the account email representation, store links and saved wallet entries and ends the account’s sign-in grants. Store-issued codes and merchant order records remain with the store. Limited records used to prevent reuse of a claim expire under wallet retention rules.

You can disconnect a signed-in store at any time on that store’s “Check my reward” page. To delete a store request or your email from it, contact us with the store you requested and the approximate time.

For questions about data processed during a specific transaction, contact us with the relevant transaction_id, idempotency_key, reward code, store, or approximate request time for investigation. Please do not send passwords or API keys.

To submit a data inquiry or exercise any rights: privacy@stabilerewards.com

7. Changes to This Policy

We may update this policy from time to time. The effective date above reflects the most recent revision. Continued use of the app after changes constitutes acceptance of the updated policy.