Privacy Policy

1. Overview

This Privacy Policy explains how One2Many LLC, an Oklahoma limited liability company (“One2Many,” “we,” or “us”), collects, uses, shares, and protects information in connection with ResellMaxx (the “Service”). Capitalized terms not defined here have the meaning given in our Terms of Service.

For Customer Data loaded into a tenant by a paying customer, we act as a data processor or service provider on behalf of that customer; the customer is the controller. For account-level data (for example, billing contact and login credentials) and our own marketing site, we act as the controller.

Two audiences, two policies. This Policy covers the ResellMaxx product and the people who run a shop on it. If you offered to sell a device or supplies to one of our customers through a storefront we host for them, that shop is the controller of your information and its own privacy policy, published on its own site, governs. We process that information for the shop and not for our own purposes.

This Policy describes what happens when a capability is in use. Several integrations described below are optional and do nothing until a customer connects an account. Where that is so, we say so.

2. Data We Collect

Account and billing. Name, business name, email, phone, the login credentials held by our authentication provider, Stripe customer and subscription identifiers, plan, and billing history. Card data is handled by Stripe; we do not receive full card numbers.

Customer Data loaded by you. Inventory records (including IMEIs, serial numbers, models, conditions, costs and sale prices), buyer and supplier contacts, invoices, bills of sale, quote submissions, diabetic supply lots, advertising metrics, IMEI-check results, conversation history, and other content you or your customers put into your workspace.

Connected accounts. We receive the account identity, authorization tokens and data described in sections 3 and 4 when you choose to connect an account.

Storefront submissions. When a member of the public asks one of our customers for a quote, we store on that customer’s behalf: name, email, phone, an optional note, the devices or supplies described, and the record of the SMS consent tick box, which includes the exact sentence shown, its version, the time, the IP address and the browser user agent at the moment of the tick. The storefront quote form does not ask for a home address, a photograph, or an IMEI.

Conversation content and attachments. Messages exchanged between a shop and a member of the public on the channels that shop has connected, together with photographs and other image attachments sent in those conversations, participant display names, booking details, and delivery state.

Marketplace alerts. For FBM Sniper and similar features, the keywords, radius and city or region you configure, and the public listing results returned for those queries.

Usage and device data. IP address, browser and device type, pages and features used, timestamps, and error diagnostics generated when you use the Service.

Storefront visit counts. On storefronts we host, we keep a first-party visit counter. It stores a one-way hash built from a secret salt, the date, the shop, the visitor IP address and the browser user agent. It sets no cookie and stores no name, email or raw IP address. The salt is replaced every night, which makes the previous day’s rows permanently unlinkable to a person. These rows are deleted after 400 days.

Communications. Emails, support requests and survey responses you send us.

3. Connected Advertising Accounts

Optional connections. Connecting a Meta or Google account, for advertising or for messaging, is optional, and only a shop owner or administrator can do it. This policy also covers invited users of our review environment. Google Ads reporting is limited to invited test users while Google OAuth verification is pending. Direct Messenger and Instagram connections are being tested in the review environment and are not generally available in the production app. Where this policy describes one of these connections, it describes what the Service does once a shop connects it. A connection accesses an account only after you authorize it.

The advertising connections are read-only. Their purpose is to show the shop its own campaign reporting, set against the enquiries and sales those campaigns produced.

Meta (Facebook and Instagram ads). We ask Meta for one permission, ads_read, which lets us read reporting and nothing else. With it we receive and store:

• The numeric user identifier Facebook assigns your account for our app, and your display name.
• The advertising accounts you can reach, with their identifiers, names, currency, time zone and status, and the one you select.
• Campaign, ad set and ad names and statuses, and daily figures for each campaign: spend, impressions, clicks, reach, frequency, link clicks, and the results Meta reports, such as messaging conversations started, leads and conversions. We also keep a record of each sync we ran.
• The access token Meta issues to us, encrypted with AES-256-GCM before it is stored. Meta does not issue a refresh token for this grant. The token expires after roughly sixty days, after which you have to reconnect.

We refresh these figures automatically, at least once a night for the last thirty days and, where more frequent refresh is switched on, up to once an hour for the most recent days, and whenever you press Sync.

Google Ads. We ask Google for three permissions. openid and email tell us which Google account connected: its email address and Google’s stable identifier for it. https://www.googleapis.com/auth/adwords is the only permission Google offers for the Google Ads API. With it we receive and store:

• The Google Ads accounts the signed-in person can reach, including manager accounts, with their identifiers, names, currency, time zone and status, and the one you select.
• For the account you select only: each campaign’s identifier, name, status and type, and daily figures for each campaign: cost, impressions, clicks, conversions and conversion value. We also keep a record of each sync we ran.
• The refresh token Google issues to us, encrypted with AES-256-GCM before it is stored, under a key separate from the one used for Meta.

We refresh these figures automatically, up to once every two hours, and whenever you press Sync. We do not receive your Google password, and we do not read your Gmail, Drive files or contacts through this connection.

We only read. These integrations read campaign reporting. They do not create, edit, pause or delete campaigns, ad sets, adverts or audiences, they do not change any budget, they do not upload images or videos, and they do not create or read Lead Ads forms. Google publishes a single permission covering both reading and writing, so its consent screen may describe more than we do. The restriction is enforced in our own software, which contains no code capable of writing to a Google advertising account. The Google integration does not create conversion actions or upload conversions through the Google Ads API. Any future campaign-management feature requires separate notice and your authorization before it acts.

Conversion events are separate. Where a shop has also configured a Meta pixel, the Meta connection is used to send the lead and purchase events described in section 6 to Meta’s Conversions API. That sends events about enquiries and sales; it does not change any campaign, advert or budget.

4. Connected Messaging Accounts

Connecting a Facebook Page or an Instagram professional account for messaging is optional, is separate from the advertising connection above, and is switched on for each connected account individually. Only a shop owner or administrator can connect one. It lets the shop read and answer the messages people send to its Page or Instagram account from inside ResellMaxx.

What we ask Meta for.

• pages_show_list, to list the Pages you manage so you can choose which ones to connect.
• pages_messaging, to receive Messenger messages sent to the Page and to send your replies.
• pages_manage_metadata, to subscribe the Page to the notifications described below. We use it for nothing else.
• pages_read_engagement, to read the Page’s own name so your inbox can label it.
• instagram_basic, to find the Instagram professional account linked to the Page and its username.
• instagram_manage_messages, to receive Instagram Direct messages sent to that account and to send your replies.
• Business Asset User Profile Access, to read the name of the person who messaged your Page or Instagram account, so your inbox shows who you are talking to.

What we receive and store.

• The Page or Instagram account identifier, its name, its Instagram username where it has one, and the permissions Meta actually granted, read back from Meta rather than assumed.
• A Page access token for each connected account, encrypted with AES-256-GCM before storage. A Page access token can both read and send as your business, so it is withheld from every database role except the server itself.
• The content of Messenger and Instagram Direct messages for that account, in both directions: what people send to your business, and what your business sends back, whether from ResellMaxx or from Meta’s own inbox. With each message we keep Meta’s message identifiers, delivery and read state, any later edit the sender made, and the raw payload Meta sent us. We keep the raw payload because a message stored incorrectly cannot otherwise be diagnosed, and it is deleted in full on a deletion request.
• Attachments. A photograph sent to your business is copied into private storage when it arrives. For other attachments, such as video, audio or a shared post, we keep only its type, name, size and Meta’s link to it, and do not copy the file.
• The name of the person in the thread. Meta’s notification does not carry it, so for each new conversation we make one extra request asking only for the fields we display: first and last name on Messenger, and name and username on Instagram. We do not request email addresses, phone numbers, profile photographs or any other profile field.
• Which advert or link started the conversation. When someone opens or returns to a conversation by tapping an advert or a link to your Page, Meta tells us the advert identifier or the link’s reference, the address it was opened from, and the details Meta attaches about the advert, such as its title and a link to its image or video. We store the first one on the conversation and match the advert to its campaign, so the shop can see which campaign produced the enquiry. Later visits do not replace it.

Notifications from Meta (webhooks). Meta sends our server a notification each time something happens in a connected account’s conversations: a new message, a reply your business sent from Meta’s own inbox, a delivery or read receipt, an edited message, a reaction or button tap, a person arriving from an advert or link, or a warning from Meta about the Page’s messaging. We check that each notification is signed by Meta before we accept it. We do not subscribe to notifications about posts, comments or anything else on your Page.

What we send. We send messages only as replies in a conversation the other person started, typed by your staff or, where you have switched it on, written by the automated assistant described in section 7. We send only within 24 hours of that person’s last message, which is the standard window Meta allows. We never publish posts, comments or stories on your Page or Instagram account, and we never change your adverts.

GoHighLevel. Where a shop connects GoHighLevel instead, the shop connects its own GoHighLevel account and we act on it with credentials the shop supplies. Contacts, messages, tags, attachments and calendar appointments pass between the Service and that account. What we send there includes the SMS consent proof described in section 2, which contains the visitor IP address and browser user agent.

5. Google User Data and Limited Use

ResellMaxx’s use and transfer of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. The restrictions in this section apply to Google data and information derived from it, and take priority over any broader wording elsewhere in this policy or our terms.

We use Google data only to provide or improve the reporting and account-connection features you can see in ResellMaxx: your shop’s own campaign reporting inside your workspace, including what each campaign cost set against the enquiries and sales your workspace recorded for it. We do not sell it, use it to advertise ResellMaxx or other products to you, use it for personalized advertising or retargeting, provide it to data brokers, or use it for credit or lending decisions. We do not use it to train generalized AI or machine-learning models, and the Google Ads reporting integration does not send it to our AI providers.

We transfer Google data only as permitted by Google’s policy: to deliver or improve the appropriate user-facing features with your consent, for security purposes, to comply with law, or in a merger, acquisition or sale of assets after obtaining your explicit prior consent. Hosting and database providers process it to operate the connection and reports. We do not send Google Ads reporting data to Meta or other advertising platforms.

Human access to Google data is limited to the exceptions permitted by Google’s policy: your affirmative agreement to inspect specific data for support; a security need such as investigating a bug or abuse; a legal requirement; or aggregated data used for permitted internal operations. General administrator access does not authorize staff to browse your Google data for unrelated purposes. These limits bind our personnel, contractors and successors.

6. Conversion Tracking and Click Identifiers

A conversion record tells an advertising platform that an advert produced a real enquiry or a real purchase. There are exactly two such events: a lead, created when someone submits a quote form on a storefront we host, and a purchase, created when the shop later records that it actually bought the device.

Click identifiers. When a visitor arrives from an advert, the advertising platform adds an identifier to the link. We read gclid, wbraid, gbraid, fbclid, msclkid and ttclid from the address and store them in a first-party cookie for 90 days, so that a visitor who returns later is still credited to the advert that found them. We also read the _fbc and _fbp cookies that Meta’s own pixel sets, where it is running. Of these, only gclid, wbraid, gbraid, fbclid, fbc and fbp are ever sent onward. msclkid and ttclid are stored on the lead record and sent nowhere, because we have no Microsoft or TikTok integration. These identifiers can relate to a person and should not be treated as anonymous.

Hashed contact information. When a conversion is queued we compute a SHA-256 hash of the email address (trimmed and lower-cased) and of the phone number (in international format, digits only), and store those hashes. The plain email address and phone number are not copied into the conversion record; they stay on the lead record where they already are. No name, address, city, state, postal code or country is hashed or sent.

Hashing does not make this data anonymous. A hashed email address is still personal information. Its whole purpose is to be matched against a platform that already holds the same email address, which is exactly what lets that platform identify the person. Treat it as identifying data, because that is what it is.

What is sent unhashed. Alongside the hashes we send the click identifiers listed above, the browser user agent string, the storefront address the visitor was on, the event time, and the value and currency of the quote. We do not collect or send the visitor IP address to any advertising platform from our servers.

Where it goes. Where a shop has configured a Meta pixel and connected a Meta advertising account, we send lead and purchase events to Meta’s Conversions API from our servers, in batches, every ten minutes. We do not send conversions to Google from our servers. Instead a shop administrator downloads a file of Google conversions and uploads it to Google themselves. Because the Meta path runs on our servers rather than in the browser, blocking cookies or using an advert blocker does not stop it.

A second path, in the browser. Where a shop has configured Google tags, the quote form also reports the conversion from the visitor’s browser directly to Google, and hands Google’s own script the email address and phone number in plain text so that Google can hash them for its Enhanced Conversions feature. That hashing is done by Google’s script inside the browser, not by us.

Consent, stated honestly. The consent banner described in section 14 controls the scripts that run in a visitor’s browser. It does not currently stop the server-side conversion pipeline above, which runs whenever a shop has the integration configured. If you need server-side conversion sending suppressed, for a shop or for one person, contact us at one2many@courtmcgee.biz and we will do it by hand. We do not currently detect the Global Privacy Control browser signal automatically.

7. AI Processing

Shops on the plan that includes it can run an automated assistant that answers messages from the public, including Messenger and Instagram Direct messages where a shop has connected those channels. This section describes what that assistant actually sends, and to whom.

Anthropic. Each time the assistant takes a turn, we send Anthropic: a fixed set of instructions; the shop profile, which is its name, service area, usual meeting area, opening hours, payment methods and price floor; the definitions of the tools the assistant may use; up to the last twenty messages of that conversation in full; a summary of the conversation so far that includes the customer name, the devices discussed, the quotes given and any booking; and the customer message itself. Where the customer sent photographs in that turn, up to four images go with it. Photographs are sent only on the turn they arrive and are not resent with later turns. Results returned by the tools, which include the shop pricing the assistant quoted and passages from the knowledge base the shop wrote, are also sent back to Anthropic within the same conversation.

A shop supplies its own Anthropic credential, so conversations on that shop run under that shop’s own account with Anthropic. One separate feature, which reads a photograph of a supply shipment to draft inventory rows for staff, runs under our credential instead.

OpenAI. OpenAI is used for one narrow purpose. When the assistant decides to search a shop’s knowledge base, the short search phrase the assistant composed is sent to OpenAI to be turned into a numeric vector for matching. The customer message is not sent, and the contents of the knowledge base are not sent. Nothing else in the Service contacts OpenAI.

IMEI scanner. When a staff member uses the IMEI scanner, barcodes are read on their own device and the camera image is not sent anywhere. When they tap Scan to read printed text, or choose a photograph, that image is sent through Vercel’s AI Gateway to Anthropic, under our credential, to read the device identifiers printed on it, such as the IMEI and serial number. That is a staff tool and is not part of the customer conversation. It is distinct from Google Ads reporting, and Google Ads data is not sent to any of these AI services.

What we will not claim. We make no promise here about how long Anthropic or OpenAI keep what we send them, or about whether it is used to train models. Our software sets no flag asking them to do or not do either. What governs is the agreement between the account holder and that provider. Where a shop supplies its own Anthropic credential, that agreement is between the shop and Anthropic, and the shop should read it. We do not sell your messages or use Customer Data to train a model of our own.

What we store. Conversations, messages, the exact instructions sent, a log of each tool the assistant called, per-turn usage figures, and queued follow-up messages are stored in your workspace. Image attachments are stored in a private bucket that cannot be read without an authenticated session belonging to your workspace.

8. How We Use Data

• Provide, operate, secure and improve the Service.
• Authenticate users and keep one workspace separate from another.
• Process payments, send invoices and manage subscriptions.
• Produce the attribution, performance and inventory reporting the workspace asked for.
• Answer messages, book meetings and send follow-ups where a customer has switched those features on.
• Send conversion records to the advertising platforms a customer has connected.
• Detect, investigate and prevent fraud, abuse and security incidents, including risk signals attached to a device.
• Send transactional and account communications, and, with an appropriate basis, product updates.
• Comply with legal obligations and enforce our Terms of Service.
• Produce counts and aggregate statistics about the Service itself, such as how many workspaces use a feature, which identify no workspace, no customer of a workspace, and no individual.

Google data is used only as section 5 allows, whatever this list says.

9. What We Do Not Do With Your Data

These are commitments, not descriptions of current practice that could quietly change. Each binds us until this Policy is changed and you are given notice under section 21.

• We do not sell Customer Data, and we do not license, rent or otherwise supply it to a data broker.
• We do not use Customer Data to advertise anything other than the Service to you, and we do not use it to advertise to your customers at all.
• We do not use one customer’s data to serve, inform, enrich or price another customer. Your buyer list, your suppliers, your costs, your margins and your conversations are not visible to, and are not an input to anything shown to, any other workspace.
• We do not publish, sell or provide benchmarks, market reports, indexes or league tables derived from Customer Data, whether identified, pseudonymised or aggregated, and whether inside the product or outside it. The counts about the Service itself described in section 8 are the only exception, and they never describe what a shop pays, charges, buys or sells.
• We do not treat data derived from Customer Data as escaping these limits. A model, score, embedding, statistic or summary computed from your data is subject to the same restrictions as the data it came from.
• We do not use Customer Data to train a machine-learning model of our own.
• If One2Many is involved in a merger, acquisition, financing or sale of assets, any successor receives Customer Data subject to this Policy and to these limits, and may not widen them without giving you notice and a reasonable opportunity to export your data and terminate. Customer Data is not a separable asset that can be sold on its own. Google data may be transferred in such a transaction only after the explicit prior consent described in section 5.

10. Legal Bases (GDPR)

Where the EU or UK GDPR applies, we rely on: (a) contract, to provide the Service you signed up for; (b) legitimate interests, to secure, operate and improve the Service in a way that is balanced against your rights and the Google data-use restrictions in section 5; (c) legal obligation, for tax, accounting and compliance; and (d) consent, where required, for example for certain marketing communications and for non-essential cookies on the storefronts where a banner is shown. Where we act as a processor for one of our customers, the legal basis for processing the information of that customer’s own customers is theirs to establish, not ours.

11. How We Share Data and Sub-Processors

We do not sell personal information. The providers below are the ones in use today. Our service providers process data to provide their service to us. Platforms a shop connects, and tags a shop chooses, handle what they receive under their own terms and privacy policies.

Infrastructure. Vercel hosts and serves the application. Supabase provides the database, authentication, file storage and secret storage. Both may process any data in the Service, including connected-account records.

Analytics and error monitoring. Vercel Analytics and Vercel Speed Insights record page views and page-performance measurements on both the application and the storefronts we host. They set no cookies and record no visitor identity. Sentry receives error reports. Sentry is configured not to send default personal information, not to record session replays, and not to sample performance traces, so what it receives is an error, a stack trace and the page path.

AI providers. Anthropic, directly and through Vercel’s AI Gateway, and OpenAI, each as described in section 7.

Payments and email. Stripe processes subscription and credit payments and holds card data. Resend sends transactional email, including account links, team invitations, booking confirmations and alerts, and therefore receives the recipient address and the message.

Messaging and CRM. GoHighLevel, where a shop has connected its own account, and Meta, for Messenger and Instagram Direct where a shop has connected a Page. Where a shop configures a Discord or Slack destination for alerts, the alert sent there contains the customer name, the device and the quote figure.

Advertising platforms. Meta and Google, for the connections described in sections 3, 4 and 6, and only the data described there. We do not send Google Ads reporting data to Meta.

Device checks. An IMEI lookup provider receives the IMEI of a device being checked and a code naming which check to run. It does not receive a customer name, email address or phone number.

Course video. Mux hosts the training videos inside the product. It receives no Customer Data.

Tags a shop chooses. On a storefront, a shop may configure Google Analytics, Google Tag Manager, a Meta pixel, Google Ads conversion tags and Microsoft Clarity. Those services then receive what their own tags collect. Microsoft Clarity records a replay of how visitors move, scroll and click, and masks the contents of form fields before anything leaves the browser. None of these run unless the shop has entered an identifier for them.

We also share data with legal and safety recipients, when required by law or to protect the rights, property or safety of One2Many, our customers or the public, and in a business transfer, subject to the limits in section 9. General sharing provisions do not override Google’s Limited Use requirements in section 5.

12. Staff Access

Our staff can reach Customer Data. We would rather say plainly what that means than imply otherwise.

A small number of One2Many personnel hold a platform administrator permission. It lets them enter a customer’s workspace and see and do what the owner of that workspace can see and do. It exists so that accounts can be supported and repaired. Every such session records who entered, which workspace they entered, the reason given, their IP address and the time, and the session expires automatically. Staff also hold the database access needed to operate and restore the Service.

Staff access is limited to operating, supporting, securing and repairing the Service, and to what the law requires. It is subject to every restriction in section 9. Google data remains subject to the narrower human-access limits in section 5.

13. Disconnecting and Deleting

These are different acts and we keep them apart deliberately. Disconnecting stops the flow and destroys the credential. Deleting does that and removes the data as well. Deleting cannot be undone.

Disconnecting. Disconnecting a Meta Page or Instagram account tells Meta to stop delivering messages for it, destroys the stored Page access token, and stops the assistant replying on that account. Your message history stays, because it is your record of what you agreed with your customers. Disconnecting Facebook Ads destroys the stored access token and deletes the list of advertising accounts it could see. It also asks Meta to remove our app’s access, unless the same Facebook account is still connected here for messaging, because Meta’s access covers both and removing it would silently stop your inbox; in that case we destroy only our copy of the Ads token. Disconnecting a Google advertising account asks Google to revoke our access, deletes the stored refresh token, and deletes the list of reachable accounts. We keep a record that the connection existed, including the email address of the Google account that made it. In both cases the reporting already synced stays, because it is part of your own reporting.

Deleting Meta data. A deletion request covering a connected Facebook account removes the stored access tokens and the connection records; your advertising account details, every campaign and daily spend figure we synced, any budget figures recorded against those campaigns, and our record of each sync. Where that Facebook account connected a Page or Instagram account for messaging, it also removes the connected Page and Instagram account records, their Page access tokens, the conversation and message identifiers Meta gave us, and the raw payloads Meta sent us. It does not remove your own business records: your inventory, your invoices, the campaigns you track by hand, the lead and conversion records your storefront created, and your message history with your customers all stay. An inventory item that was linked to a deleted Facebook campaign stays, without that link. The irreversibly hashed email address and phone number of someone who contacted your shop directly also stay, because those describe that person rather than your Facebook account, were never obtained from Facebook, and are your own lead record. We verify requests, and we will explain any record we keep and why.

Deleting Google data without closing your workspace. Email one2many@courtmcgee.biz and request deletion of your Google connection and imported Google Ads data. After verifying your authority, we will remove the connection, stored credentials, account list, imported Google campaign and performance records, and associated sync records, including the record that the connection existed. Your unrelated inventory, invoices and other workspace records are not part of that request. Any legally required retention will be explained and limited to that purpose.

How to do either. In your workspace, under Settings and then Integrations, each connection that is available to your workspace has its own controls: Disconnect for Facebook Ads and for Google Ads, and, for a connected Page or Instagram account, controls to disconnect it and to request deletion of everything we hold for the Facebook account behind it, across advertising and messaging together. In-product controls may differ between the production app and the review environment; the routes below always work. You can act from Facebook itself: open Settings and privacy, then Settings, then Apps and websites, select ResellMaxx, and either remove it, which disconnects, or use Send Request to ask for deletion. A deletion request made either way returns a confirmation code and a link to a page reporting what was removed. On Google, open your Google Account connections, select ResellMaxx and remove access. You can also email us for any of these.

What disconnecting does not do. Disconnecting an advertising account does not pause, stop or change anything running in it. Campaigns keep running and keep spending until you change them in the advertising platform itself.

Deleting a whole account, and exports. There is no self-service control for deleting a workspace, or for deleting an individual record on request. Email one2many@courtmcgee.biz and we will verify your identity and authority and carry it out within applicable legal timeframes. Likewise, the only self-service export today is your billing credit ledger; ask us and we will produce a copy of the rest.

If you messaged a shop on Facebook or Instagram. You can ask the shop you messaged, or email us at one2many@courtmcgee.biz, to delete what we hold about you from those conversations. Tell us which shop you messaged and the name on your Facebook or Instagram account. We will find your messages, your name and the identifiers Meta gave us for you in that shop’s workspace, delete them, and tell the shop we have done so. This is done by hand, not by a control in the product.

14. Cookies and Analytics

In the application. We use cookies that are strictly necessary: the session cookies set by our authentication provider; a short-lived cookie used while a buyer account is being linked; and, while a member of our staff is supporting an account, two cookies that hold the staff session and mark that support session. We set no advertising cookies in the application. The advertising connections do not install an advertising pixel or track visitors on your behalf.

On storefronts we host. We set one first-party cookie for 90 days holding only the campaign parameters and click identifiers already present in the address the visitor arrived on, plus the referring page. It holds no name. A visitor’s answer to the consent banner is stored in the browser rather than in a cookie.

Where a shop has configured them, Google, Meta and Microsoft Clarity tags set their own cookies, including _ga, _fbp, _clck and _clsk.

The consent banner. Storefronts belonging to shops based in Canada, the United Kingdom or the European Economic Area show a consent banner, deny all advertising and analytics storage until the visitor answers, and hold the Meta pixel and Microsoft Clarity back entirely until the visitor accepts. Storefronts belonging to shops based elsewhere do not show a banner, and their tags run on load. As stated in section 6, this banner governs scripts in the browser and does not currently suppress server-side conversion sending.

The shop is responsible for its storefront privacy disclosures and lawful tracking choices. You can manage cookies in your browser and contact the shop about tracking on its storefront.

15. Data Retention and Backups

We would rather give you the real position than a schedule we do not keep.

• Storefront visit counts are deleted automatically after 400 days, and the salt that makes them linkable is destroyed every night.
• Access tokens for Meta and Google are destroyed when you disconnect in ResellMaxx. Meta tokens are also destroyed when you remove our app in Facebook’s settings or a deletion request arrives. If you remove our access on Google’s own page instead, Google stops the token working at once, and our encrypted copy is deleted when you disconnect here or ask us to.
• Facebook and Instagram messages, the names of the people in them, the advert or link that started each conversation, and the raw notifications Meta sent us, are kept while the account is active. Disconnecting keeps the messages; a deletion request removes the Meta identifiers and raw notifications as set out in section 13.
• Advertising reporting synced from Meta or Google is kept while the account is active, including after you disconnect. It has no automatic fixed-age deletion schedule. A Meta deletion request removes the Meta figures. Ask us and we will delete the Google figures.
• Everything else, which includes inventory, invoices, contacts, quote submissions, conversations, attachments and conversion records, is kept for as long as the account is active. We do not currently run an automatic deletion after a fixed period. That means a conversion record, and the hashed email address and click identifiers in it, is kept indefinitely unless you or we delete it.
• After you leave, we keep Customer Data only as long as needed for restoration, disputes, fraud prevention, security and legal obligations, then delete it. Ask us and we will delete it sooner.
• Billing records are kept for as long as tax law requires, typically up to seven years.
• Backups. Our database provider takes backups on its own schedule. A record you delete remains in a backup until that backup ages out, so deletion from the live database is not instantaneous everywhere. Any restoration from a backup must reapply completed deletions.

16. Security

We use administrative, technical and physical safeguards, including encryption in transit, row-level security in the database so one workspace cannot read another, live re-checking of a user’s membership and role on every request rather than trusting a token issued earlier, least-privilege access and audit logging. Advertising and messaging tokens are encrypted with AES-256-GCM before they are stored, and the credentials a shop supplies for its own messaging and AI accounts are held in an encrypted secret store reachable only by the server. Customer photographs are stored in a private bucket that is not publicly readable.

No system is completely secure. You are responsible for safeguarding your credentials and for the data you load. We will notify affected customers, and where required regulators, of a confirmed personal-data breach without undue delay.

17. Your Rights

Depending on where you live, you may have rights to access, correct, delete, port, restrict or object to processing of your personal data, and to withdraw consent. To exercise these rights, email one2many@courtmcgee.biz. We will verify your request and respond within the timeframe required by applicable law. As set out in section 13, most of these are handled by us on request rather than by a control in the product.

If you are a member of the public whose information was collected by one of our customers, please direct your request to that shop. Its privacy policy on its own site names how to reach it. We will assist the shop as its processor, and we act on its instruction. If you messaged a shop on Facebook or Instagram, you can also ask us directly, as section 13 explains.

18. California Residents (CCPA/CPRA)

California residents have the right to know what personal information is collected, to delete it, to correct inaccurate information, and to limit the use of sensitive personal information, subject to exceptions. You will not be discriminated against for exercising these rights.

We do not sell personal information. Sending information to an advertising platform in the way described in section 6 may count as “sharing” for cross-context behavioral advertising under California law. Where we do that for one of our customers, that customer is the business making the decision and its own site carries the opt-out. Where you deal with us directly, email one2many@courtmcgee.biz to opt out. We do not currently detect the Global Privacy Control signal automatically, so please tell us.

19. International Transfers

The Service is operated from the United States, and our database and hosting providers process data there. Customers in Australia, Canada and the United Kingdom use the same infrastructure. If you access the Service from outside the United States, your data will be transferred to and processed in the United States and in other countries where our providers operate. Where required, we use appropriate safeguards such as Standard Contractual Clauses.

20. Children

The Service is not directed to children under 16, and we do not knowingly collect personal information from children. If you believe a child has provided us personal information, contact us and we will take appropriate steps to delete it.

21. Changes to this Policy

We may update this Privacy Policy from time to time. The “Last updated” date at the top reflects the latest version, and earlier versions are linked beneath it. For material changes, including any change to the limits in section 9, we will give notice by email or an in-product notice before they take effect.

22. Contact

Privacy questions or requests? Contact us at one2many@courtmcgee.biz.

One2Many LLC, Oklahoma, U.S.A.

See also our Terms of Service.