QueueFront privacy policy

Effective date: 2026-10-08

QueueFront is a service of AtlasFlare LLC. This policy explains how QueueFront handles information when a Shopify merchant installs or evaluates QueueFront, when merchant staff use the embedded app, and when shoppers encounter a QueueFront waiting room, product waiting list, notification signup, or protected checkout.

Our role

For customer personal data that a merchant makes available through Shopify, the merchant generally determines why the data is processed and QueueFront processes it to provide the service. The merchant remains responsible for its storefront notices, lawful basis, consent choices, and responses to its customers. AtlasFlare LLC may act for its own purposes when it secures the service, manages accounts and billing, prevents abuse, or meets legal duties.

Shopify is a platform selected by the merchant and has its own terms and privacy practices.

Information QueueFront handles

Merchant and administrative information

Shopify shop ID and domain, display name, timezone, currency, installation state, plan, configuration versions, and onboarding milestones;
authenticated Shopify staff-session information supplied for app access, such as staff ID, name, email, locale, and account role;
event schedules, protected products/variants/collections, inventory and location choices, capacity rules, branding, and feature settings; and
audit records describing administrative actions, request IDs, and bounded before/after summaries; and
merchant agreement versions, document fingerprints, confirmation wording and acceptance timestamps, linked to the authenticated store and, when available, the authenticated Shopify staff identifier.

Shopify access and refresh tokens, OAuth state, and stored staff-session identity are encrypted at rest.

Shopify Sidekick-assisted setup

When a merchant chooses Shopify Sidekick-assisted setup, QueueFront receives structured suggestions through the setup link the merchant opens. Supported fields include the setup type, product ID or title, room name, opening time, admission rate, active admission limit and queue capacity. QueueFront validates the suggestions and checks the product against the signed-in store before prefilling its ordinary setup form. The merchant reviews and saves the form; opening a setup link does not itself save or publish a room, send notifications, change billing or manage an existing room. The setup-link integration does not request the merchant’s full Sidekick conversation. Shopify provides Sidekick under its own platform terms and privacy practices.

Shopper, order, and queue information

protected Shopify customer and order IDs and protected order-line product, variant, and quantity details;
an app-owned customer metafield containing QueueFront event identifiers for the current one-protected-purchase rule;
event-scoped digests or tenant-keyed hashes of customer IDs, keyed admission, queue-session, and network identifiers, plus queue tier and admission outcome;
a short-lived encrypted one-use Shopify redemption code and admission JTI, with hashes used for ordinary binding and reconciliation state;
event participation state, timestamps, inventory observations, challenge results, and aggregate performance metrics; and
authenticated Shopify privacy-request identifiers and encrypted reports.

The release waiting-room and checkout path does not request or persist Shopify customer names, emails, phone numbers, billing or shipping addresses, or customer tags. Customer-tag loading and matching are disabled by the server-side release gate and require a policy/declaration update before activation. An enabled Waiting List may separately collect an email address, and an eligible merchant may separately offer Text me. SMS requires purpose-specific consent; QueueFront encrypts the normalized phone number and uses a tenant-keyed digest for lookup, suppression, and privacy matching. A phone number supplied elsewhere in Shopify is not silently enrolled in SMS.

Shopify’s mandatory privacy webhooks may include contact fields in their request body. QueueFront authenticates and processes those fields in memory to match an applicable email or SMS consent record but does not persist the raw privacy payload. The application does not retain raw privacy-webhook bodies or raw IP addresses from these requests.

When an eligible merchant enables a dedicated SMS number, QueueFront may open Twilio Compliance Embeddable for carrier-required business verification. The regulatory questionnaire is submitted directly to Twilio. QueueFront keeps only bounded inquiry and registration references, lifecycle state, reason code, and timestamps; any legacy encrypted registration payload is purged.

Email delivery and link activity

Enabled email notifications are delivered through Resend. QueueFront keeps message identifiers, delivery and failure states, unsubscribe/suppression data, and the first reported link-click timestamp for delivery reporting. The managed sending domain currently has click tracking enabled and open tracking disabled. Tracked links pass through a provider redirect before reaching their destination. Resend’s click-event data can include the link, time, IP address and browser user agent; QueueFront’s webhook handler records the correlated event and timestamp, not the raw click IP address, user agent or webhook body. Provider processing and retention are separate from QueueFront’s application storage.

Public website measurement

Cloudflare Web Analytics can measure public page views and page performance using a browser beacon added by Cloudflare. This is separate from waiting-room admission and email link tracking. Cloudflare describes this service in its Web Analytics documentation and processes the measurement under its applicable terms.

Information supplied voluntarily

If a merchant contacts support or reports a security issue, QueueFront handles the message and contact details needed to investigate and respond. Reporters must not include passwords, access tokens, admission tokens, payment data, or unnecessary shopper information.

Why QueueFront uses information

QueueFront uses information only to:

authenticate merchants and isolate Shopify tenants;
configure and operate waiting rooms and checkout validation;
preserve authoritative admission order, inventory/capacity enforcement, reconnect identity, priority behavior, and admission-token integrity;
reconcile protected orders and apply the app-owned purchase marker;
detect replay, diagnose service health, prevent abuse, and investigate security or correctness incidents;
provide merchant audit, diagnostics, support, billing, and privacy functions;
deliver merchant-configured transactional Waiting List and Waiting Room email or SMS notices, honor channel-specific consent and STOP suppression, and account for carrier-billed usage;
answer Shopify customer-data and deletion requests; and
comply with applicable law and enforce QueueFront’s agreements.

QueueFront does not sell personal information, share it for cross-context behavioral advertising, or use Shopify Merchant Data or Customer Data to train artificial-intelligence or machine-learning models. Post-Beta VIP, email allowlist, customer-tag, marketing, related-product, and expanded duplicate- buyer features are off and do not authorize additional processing.

Operational monitoring includes the existing RunCloud AI Monitoring path described in the subprocessor disclosure. AtlasFlare uses it for internal server diagnostics under the provider terms described there; the no-training statement is not a claim that no AI processing is used for server diagnostics.

When information is disclosed

QueueFront discloses information only:

to the merchant that controls the relevant shop;
to service providers listed in the QueueFront subprocessor disclosure, under contractual and access restrictions;
to Shopify when required to operate the integration or answer a platform request;
when required by law or reasonably necessary to protect rights, safety, checkout integrity, or the service; or
in a corporate transaction subject to appropriate confidentiality and continued protection.

QueueFront does not expose one merchant’s data to another merchant.

Admission tokens and one-use redemption codes are bearer-equivalent secrets. QueueFront does not put them in URL paths, query strings, redirects, analytics, or ordinary request-target logs. The browser receives a pair through an authenticated POST and keeps it in transient, event-scoped session storage.

Retention

QueueFront retains information for the service, security, privacy-response, consent and accounting purposes described above. Retention depends on the record’s purpose, the event or subscription lifecycle, unresolved delivery or billing work, and applicable deletion requirements. Uninstall, unsubscribe and deletion of a Shopify shop are different actions with different effects.

QueueFront uses category-specific automated cleanup and a monthly manual retention review. The table describes which controls are automated today. For other records, the manual review periods below apply; these do not imply an automatic deletion job or override a valid earlier deletion request.

Information	Current handling
Shopify credentials and staff sessions	Deleted on authenticated uninstall.
Raw compliance-webhook bodies	Processed in memory; not persisted by the application.
Encrypted privacy reports	Access expires 30 days after generation. For the two retained development/test stores, daily bounded cleanup clears expired completed report bodies while preserving request receipts and result evidence. Access checks also purge expired reports; applicable customer/shop redaction can remove them earlier. Scheduled cleanup pauses for maintenance holds or an expired review and is not yet enabled for other installations. Access expiry is not a guarantee of physical removal at that exact time.
Queue sessions and encrypted admission credentials	Event/session validity limits access. Redemption, binding expiry, event retirement or applicable shop deletion trigger the corresponding redaction paths. These limits are not a blanket expiry rule for every audit or replay record.
Analytics	For the two retained development/test stores, approved daily maintenance removes minute metrics older than 90 days, hourly metrics older than 12 calendar months and daily metrics older than 24 calendar months. It clears final totals more than 24 calendar months after event end while preserving a cleared marker. Only ended/cancelled events qualify; active holds stop maintenance. Bounded batches and dependencies can extend the interval. This schedule is not yet enabled for other installations.
Email/SMS contacts, message copies and confirmation tokens	For the two retained development/test stores, daily bounded cleanup clears eligible settled email message copies after more than 30 days and verified never-claimed expired confirmations after more than seven days. It clears eligible unsubscribed email contacts after more than 30 days and expired unconfirmed email contacts after more than seven days. SMS message-copy cleanup requires more than 30 days after both latest delivery/accounting activity and billing-period end. Each clock depends on the latest relevant activity, resolved usage and safe worker/lease history; these are not universal removal deadlines. Unsubscribe or STOP does not itself erase records. For these two stores, eligible opted-out SMS phone contacts are cleared after more than 30 days since the latest relevant activity, only after their message copies are purged and delivery/accounting work is settled. Contacts without an explicit opt-out timestamp and histories outside the bounded review limit are excluded. Minimum consent, suppression, contact digests and accounting evidence remain. Active/closed subscriptions outside these categories and other installations are not enrolled. Applicable customer/shop redaction remains separate.
Consent and suppression	Minimum consent and channel-scoped opt-out evidence is kept to honor shopper choices and investigate consent issues. A digest can still be personal data. No automatic expiry currently re-enables sending, and age-based review follows the manual schedule below.
Administrative, admission, replay and provider receipt records	Kept for diagnostics, security, privacy and safe replay/accounting. Waiting-room design audit summaries retain heading/body lengths rather than duplicate text; the saved designs are separate. Persisted webhook failure diagnostics use fixed labels. General automatic age-based removal is not enabled; manual review applies as described below. Deduplication and accounting evidence must be separated from removable detail.
Merchant agreement receipts	When a merchant accepts through the agreement screen, QueueFront records document versions, fingerprints, confirmation wording and acceptance time with the store’s agreement history. Receipts remain after uninstall until applicable shop redaction removes them; no separate archive surviving shop redaction is maintained.
Support correspondence	Kept in Fastmail for the relevant request, dispute or privacy/security purpose. Case closure and exceptions are reviewed manually; a fixed mailbox expiry is not yet enabled. These messages are not covered by application cleanup timers.
Merchant-facing app bills and payment records	Handled through Shopify billing under the merchant’s Shopify relationship. QueueFront does not run a separate merchant invoicing or accounting service.
QueueFront subscription, usage and reconciliation records	QueueFront keeps plan/subscription references, usage periods and counters, reservation/replay keys and provider/Shopify reconciliation evidence to operate allowances and resolve billing activity. These are separate from Shopify’s bills. Shop redaction removes subscription/commercial usage records with the tenant but retains the separate telecom usage ledger and privacy-request completion/replay evidence. The telecom ledger includes store and provider/Shopify references and is not anonymous aggregate data. Manual review of settled reconciliation evidence follows the schedule below; retained personal data still requires an applicable purpose and deletion handling. Unrelated message bodies or contact data are not retained merely because billing evidence remains.
Production application and worker logs	The three production process streams retain the current UTC date and the preceding 14 complete UTC dates, approximately 14–15 days, with at most four 10 MiB files per stream. Size pressure can remove closed files sooner. Age cleanup runs while the process is running and resumes at startup after a stop. Existing logs migrated on October 8, 2026 UTC use that cutover date for age cleanup; their contents were preserved. This rule does not cover proxy, database, shared Supervisor, small wrapper-failure or provider logs.
Carrier verification	The questionnaire is submitted directly to Twilio. QueueFront retains bounded references and state and purges legacy encrypted questionnaire payloads. Provider-held records follow the applicable provider terms.
Provider monitoring and delivery records	Subject to the provider’s own processing and retention described in the Subprocessor Disclosure, separately from application storage.
Database backups and recovery copies	Native backup targets are 30/35 days with backup-chain dependencies. Sealed recovery copies have a 30-day lock and a separate 35-day object-expiration rule; processing delays and older chains inside a copy mean this is not a maximum personal-data age.

The analytics, five email/SMS, privacy-report and opted-out SMS contact cleanup reviews currently expire November 6, 2026. Each category stops if its review is not separately renewed. These automated schedules currently cover the two test stores. Other categories use the manual review procedure; further stores require enrollment. Changes to these practices will be reflected here before broader use.

Manual review periods

Records not removed earlier by the applicable privacy or product lifecycle are reviewed monthly. The responsible operator records any continued purpose and next review date, or prepares a scoped removal/minimization action. The ordinary review thresholds are:

Active waiting-list contacts: at list closure and after 12 months without signup, confirmation or notification activity. Keep a contact only while the requested list purpose remains current; do not treat an old signup as new consent.
Consent and suppression: retain the minimum needed while the related channel remains active. Review closed-list consent evidence after 12 months; preserve a minimal opt-out marker where necessary to prevent renewed unwanted messages.
Ordinary closed-event audit details: 12 months after both the edit and event end. Other security or dispute evidence is assessed against the specific case.
Completed privacy and settled delivery/replay evidence: review after 12 months. Remove unnecessary detail separately from minimal keys still needed to prevent repeat processing; any extension must have a recorded reason and review date.
Settled telecom reconciliation evidence: review 12 months after final billing reconciliation and any correction or dispute closure. Keep only what remains necessary for an identified billing or legal purpose.
Ordinary support cases: 12 months after explicit closure. Reopened cases, privacy/security investigations and disputes are reviewed under their active purpose rather than silently treated as closed.

These are review thresholds, not a promise of physical erasure on that day. Unnecessary data must be removed or minimized through a verified, scoped action; reviews do not authorize indefinite retention. New merchant onboarding includes retention enrollment and any required transfer safeguards before ordinary live use. The current application does not automatically enforce that onboarding check; it is an operator responsibility.

Maintenance holds apply only to their corresponding cleanup tools. They do not form a service-wide legal-hold system and do not automatically suspend a valid privacy request. The ordinary application account cannot approve cleanup, renew reviews or release maintenance holds.

A legal or security hold must be documented, tenant-scoped, access-restricted, and removed when no longer required. Backup copies are encrypted and isolated from ordinary product access. They are not selectively edited; deleted data is not returned to active use. Native backup-chain expiry and sealed recovery-copy deletion are separate operations. Sealed copies can contain older backup chains, so these intervals do not promise that all deleted personal data disappears within 35 days. Restores remain isolated until applicable deletion records are reapplied. Lock expiry alone does not delete a copy; the separate lifecycle schedules deletion.

Security and access

QueueFront uses tenant scoping, TLS, encrypted sessions and secrets, encrypted off-host backups, and a dedicated encrypted volume for its production database, transaction logs and retained migration recovery files. Other controls include environment separation, least-privilege database roles, loopback-only PostgreSQL, audit logs, bounded token validity, per-event Ed25519 signing, and fail-closed checkout controls. Staff access is limited to people with an operational need using individually controlled, strongly authenticated accounts. No system is perfectly secure; the Security page describes the reviewed posture and reporting process.

Data location and transfers

QueueFront’s providers can process information in countries other than the merchant’s or shopper’s country. The merchant-data agreement and subprocessor disclosure describe the processing chain. Where a transfer requires additional safeguards, QueueFront and the merchant must complete them before that processing begins. Contact [email protected] for the applicable private transfer terms; publishing this policy does not execute a merchant-specific transfer contract. The control-plane host is verified in US East/Vinthill, United States; that location does not describe all edge, backup, email, management or downstream processing.

Privacy choices and requests

Shoppers should submit access, correction, or deletion requests to the Shopify merchant from whom they purchased or attempted to purchase. Shopify then sends the applicable authenticated compliance request to QueueFront. QueueFront provides the result to the merchant and performs deletion or redaction within the required period, subject to a documented legal obligation to retain it.

Merchants can use QueueFront’s authenticated Privacy & trust screen to review available lifecycle evidence. Receipt of a request is not represented as proof that every external delivery or backup-expiry step has already completed.

Children

QueueFront is a business service for Shopify merchants and is not directed to children. Merchants are responsible for the age, consent, and storefront rules that apply to their products and customers.

Changes and contact

Material policy changes will be identified by an updated effective date and, when appropriate, merchant notice before they take effect. Privacy questions use [email protected]. Security reports use [email protected] and follow the Security page guidance. Both are monitored reporting channels.