Privacy Policy

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

This Privacy Policy describes how Stabile: Loyalty Rewards Agent and StabileRewards AI (“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 in three ways, each described below: 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.

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

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.