Companies that receive Boosthis data

Moyasar

What it does: payments — embedded payment form and subscription charges

What reaches it: card details sent directly from the browser through Moyasar's form embedded in Boosthis-hosted checkout (never to Boosthis's servers), the amount and currency of each charge, the billing name and email on the payment, and the reusable payment token that makes a renewal work

Processed in: Kingdom of Saudi Arabia

On whose instructions: Moyasar is not only our processor, and no term could make it one. It is a payment institution licensed and supervised by the Saudi Central Bank, and the card data a buyer enters through Moyasar's embedded form on Boosthis-hosted checkout is sent directly from the browser to Moyasar and handled under its own regulatory and card-scheme obligations — anti-money-laundering checks, fraud screening, chargeback handling and record keeping it must perform whatever we instruct. What it does for us on our instruction is narrow and named beside it: take the charge we ask for, and tell us whether it succeeded. Recording it as instruction-only would be a term neither side could keep. Its published terms.

Its own sub-processors: Moyasar publishes no sub-processor list. Its privacy notice describes disclosures to banks, card schemes, regulators and service providers in general terms, without naming them, so there is no list to read and no list to watch. This is a real gap in what we can tell a customer, not a finding about the provider: for a licensed payment institution it is the ordinary published posture in this market. None published. Because there is no list, a change to it is not something we could be told about or detect; what we can see is a change to the privacy notice itself, which is the source recorded above.

Onward transfer: Its privacy notice states that personal data is collected and processed within the Kingdom of Saudi Arabia in compliance with the Saudi PDPL. Nothing on this path is recorded as crossing a border, which is why this recipient carries no transfer basis above. Nothing we hand this recipient may leave the Kingdom without the recipient list and the transfer register saying so first. That is checkable rather than promised: the register's own guard fails when a recipient's processing location moves outside the Kingdom and no transfer basis is recorded beside it, and the published residency sentences are generated from this record rather than typed.

Resend

What it does: email delivery — the account emails listed under Account data

What reaches it: your email address, the subject, and the body of the message

Processed in: United States · Why it may leave the Kingdom: The account emails a customer asks for — the sign-in code, the receipt, the alert they configured — cannot be delivered without handing the address and the message to a delivery provider. The transfer is necessary in order to provide the hosted service the customer signed up for, it is disclosed in the recipient list before they sign up, and it carries only that one message.

What limits that transfer: What leaves is one address and one message, and the message is the whole of it. Some messages are only a code or a receipt; an alert states the finding and names the app it concerns; a monthly summary states that account's own figures. Nothing travels beside the message — there is no telemetry feed to this recipient and nothing else about the account is sent with it.; Resend is engaged as a processor under its published Data Processing Addendum and may use what it receives only to deliver that message.; There is no marketing or broadcast path: every send is one address, and the customer stops all of it by closing the account..

On whose instructions: Resend publishes a Data Processing Addendum that applies to its customers by its terms rather than by signature, under which it acts as processor for the customer data it handles and processes it on the customer's documented instructions. Our instruction is the whole of what the recipient list says reaches it: deliver this one message to this one address. There is no marketing path, no list upload and no second use to instruct it out of. Its published terms.

Its own sub-processors: Resend publishes a named sub-processor list at its own address, which is the strongest of the practices recorded here: the companies are named, not described by category, so a change is visible rather than inferable. Read on the date below; the list at that reading was entirely United States companies, which is also what the residency evidence above rests on. The list is published and dated by the provider. It is the provider's own page, not a commitment made to us, so what we rely on is the weekly re-reading recorded below rather than a promise of notice. Its published list.

Onward transfer: Its addendum engages sub-processors under terms it undertakes to keep no less protective than its own, and its published list is where a change to them shows up. What it holds — account data, email metadata and logs — stays in the United States whichever sending region is used, so an onward move is a move between United States companies rather than into a new country. A sub-processor this recipient adds is an onward transfer of one address and one message, and it reaches a customer the same way our own list does: named on the published recipient page before it begins, on the notice period stated there. That is not left to somebody noticing — `subProcessorWatch.ts` re-reads the page above on a weekly clock, compares it with the digest recorded here, and puts a change on the operator's own alert surface until a human has read it and moved this entry.

OpenAI

What it does: AI processing — answers from the Ask Boosthis assistant, and the scheduled rule-drafting pass. Two companies sit in this path: the call leaves Boosthis to an AI gateway operated by Replit, on Replit's own account and credential, and Replit passes it to OpenAI, which generates the answer. Replit is also the hosting recipient listed separately; on this path it is the intermediary, and what it can see is the call itself

What reaches it: the screened question and the privacy-safe digest described in the assistant section, and — for drafting — aggregated privacy-safe signals; one short sentence a developer or their assistant wrote, where a promise or a submitted claim cannot be read by the plain word match and the account owns the project, sent once so it can be mapped onto one subject the project already measures — and, in the same call, the list it has to choose from: up to forty of that project's own subjects, each a route, problem, job or daily-reading label with the figures already measured for it, which is that project's own data and not pooled with anyone else's; separately, the text of our own rule book, which is ours rather than a customer's: rule titles, match conditions and detector patterns, plus the prescriptive fix text on the maintainer-side drafting and review calls that cannot work without it; the provider's published position for its API is that none of it is used to train AI models

Processed in: United States · Why it may leave the Kingdom: Three things reach this recipient, and two of them are a customer's own doing. The assistant cannot answer without a model, and it sends only when a customer asks it something: a question that passed the PII guard, and a privacy-safe digest of numbers. One short sentence reaches the model on the same footing, and only ever because somebody on the account did something that asks for it: a developer typing a standing promise into their own dashboard that the plain word match cannot read, or the checking they arranged themselves — their own Stop hook, or an assistant they connected calling the check tool. It is screened and sent once, so the sentence can be mapped onto one subject the project already measures, which is the matching they wrote it for. That call carries the shortlist it has to choose from as well — up to forty of that project's own subjects with the figures already measured for them — because nothing can be mapped onto a list the model cannot see. It is one project's own data, not pooled, and it goes for the same reason the sentence does. The rule-drafting pass also cannot draft without a model, and it runs on our schedule rather than anyone's request — what it sends is counts and server-authored terms pooled across projects, never one project's data on its own. All three are necessary to provide what the service offers, and all three are disclosed before an account exists.

What limits that transfer: Every prompt is screened by the PII guard at the point it is sent — the assistant's question and digest, and the maintainer-side drafting and review calls alike — and the answer is screened again before it is shown. Be precise about what that screen is: it refuses the whole call on an email address, a telephone number, an IP address or a token, and those are the shapes it knows. It is not a promise that nothing a person types by hand into a question could ever identify them. Two things travel on purpose. Our own security guidance names reserved, non-routable addresses — the loopback address and the cloud metadata endpoint — which identify nobody and are the whole point of the rule that names them. And a question from a signed-in customer carries a safety identifier: a one-way salted digest of the account, sent so the provider can rate-limit and investigate abuse, and which tells it nothing about who the account belongs to.; OpenAI's published position for its API is that what it receives is not used to train its models; that position was read on 14 September 2026. It is the provider's default for API traffic, and turning it off is a choice made on an account — so it is a reading of the provider's terms, not a promise we are in a position to enforce.; How long a prompt survives at the other end is NOT established, and is recorded as unknown rather than assumed. Boosthis reaches the model on the gateway operator's account rather than one of its own: OpenAI's published default deletes an API input after at most 30 days of abuse monitoring, but whether this account runs on that default is not published. The gateway operator publishes a position of its own, read 15 September 2026, and it settles nothing here: training is disabled for paid model providers, and zero-retention endpoints are enforced for Enterprise accounts only — neither branch names the plan this path runs on. The gateway also publishes nothing about what it logs. The working, with its dates, is in docs/ai-provider-data-posture.md and the same answer is declared in code on lib/aiProvider.ts.; Both of the paths that carry one project's own data are switched on by the customer. A customer who never asks the assistant anything, and never writes a sentence for us to match — a standing promise the plain word match cannot read, or the checking they arranged themselves through their own Stop hook or an assistant they connected — sends nothing of their own to this recipient. The scheduled drafting pass still runs, so their measurements can be folded into it — but only as counts, and only pooled with other projects. Nothing that names a project, an install or a person is in the type the pass can send..

On whose instructions: Boosthis holds no agreement with OpenAI, and saying otherwise would be the cross-referencing this entry exists to remove. The call leaves us to Replit's AI Integrations gateway on Replit's own account and credential, and Replit passes it on — so the company we instruct is Replit, under the terms recorded on its entry below, and OpenAI is its sub-processor rather than ours. OpenAI publishes processor terms and a sub-processor list of its own, and they are the right documents for the relationship; they are simply not a relationship we are a party to. What binds this path for a Boosthis customer is therefore Replit's instruction-only term, and what limits it in practice is the screening described in the safeguards above: the PII guard refuses the whole call before it is sent, and screens the answer again before it is shown. Its published terms.

Its own sub-processors: OpenAI publishes a named sub-processor list at its own address. It is the one list here that this server cannot read: the page is served behind a check that refuses an automated request outright, so the weekly watch can report that it could not look, and never that the list is unchanged. That distinction is the point — a checker that read a refusal as "no change" would be worse than no checker. Whatever the provider commits to on that page is a commitment to its own customers. We are not one, so no notice from it would reach us; a change here reaches us through the recipient we do contract with. Its published list.

Onward transfer: Every onward step on this path is already an onward step: what reaches OpenAI got there because Replit passed it on. Its published residency options for the API are the United States and Europe, and the Kingdom is not among them, which is why this entry certainly leaves the Kingdom and why which country actually processes it is recorded above as unconfirmed rather than assumed. This is the one path where our recourse is at one remove, and it is written down rather than glossed: a change of model provider behind the gateway is Replit's to make, and what we hold is the right to be told through Replit's own sub-processor list and the option to stop using the gateway. Two things make that less thin than it sounds. The published claim that what the API receives is not used to train models is recorded against its source and its reading date, so it cannot quietly become folklore. And the switching cost above is written out, so moving off this path is a decision somebody can price rather than discover.

Replit

What it does: hosting and the managed PostgreSQL database, and the AI gateway in front of OpenAI

What reaches it: everything this document describes as stored: account data, telemetry, and the operational database as a whole

Processed in: United States · Why it may leave the Kingdom: Everything the service stores lives on the infrastructure the service runs on. Until the service itself runs in the Kingdom, that is where all of it is. The transfer is necessary in order to provide the hosted service, and it is disclosed before an account exists.

What limits that transfer: The database is private to this service. Nothing in it is shared with another tenant, sold, or used for anything the disclosure does not name.; Backups of it are held in the private bucket described under the backup-storage recipient, in the same geography, and rotate out on the published schedule.; A customer who wants nothing to cross a border can run a general install of the toolkit, which sends nothing anywhere..

On whose instructions: Replit publishes a Data Processing Addendum that forms part of its terms of service rather than needing a signature, under which it processes customer content as a processor on the customer's documented instructions. This is the widest instruction of the five and the one worth stating precisely: our instruction to this recipient is to run the service — compute, the managed database, object storage and the gateway in front of the model — and everything the privacy policy describes as stored is inside it, because the service cannot run otherwise. Its published terms.

Its own sub-processors: Replit publishes a named sub-processor list at its own address. It is the most load-bearing of the five, because two of the other companies on our own list are reached through this one: the model provider behind the AI gateway, and the object storage behind the backups. A change to this page is therefore the change most likely to move something a Boosthis customer would care about. The list is published and dated by the provider, and its addendum is where any commitment about changing it lives. Because two of our recipients sit behind this one, the weekly re-reading recorded below is the signal we actually act on. Its published list.

Onward transfer: Its addendum engages sub-processors under terms no less protective than its own and identifies them on the page above. Its geography documentation says a published app's compute, database and object storage are colocated in the geography chosen, which is what keeps an onward move from silently becoming a move to a new country: the geography is ours to choose, and it is North America today. Because this recipient's own list is where two of our recipients appear, a change to it is treated as a change to ours: the watch compares the page weekly against the digest recorded here, raises it on the operator alert surface, and it stays raised until a human has read the page and moved this entry. If a change means another company starts receiving customer data, it is named on the published recipient page before it begins, on the notice period stated there.

Google Cloud

What it does: backup storage — the routine encrypted database backups described under Retention

What reaches it: a copy of the operational database, in a private bucket

Processed in: United States · Why it may leave the Kingdom: A backup is a copy of the operational database, so it is wherever that database is until the service moves. Keeping a recoverable copy is necessary in order to provide the hosted service, and the copy holds nothing the database does not already hold.

What limits that transfer: The bucket is private and reached through a loopback sidecar that holds the credentials. There is no public address for it.; Routine backups rotate out within 30 days, so data erased from the service leaves the copies as they rotate. Two narrow exceptions, both already published under Retention and both visible in the rotation code: a particular set is occasionally held past that window when it is the last remaining evidence in an open question about our own records — every hold recorded with its reason and lifted once the question is answered — and a small, separate copy of the records we are required by law to keep (payment and receipt records) is kept for as long as that obligation lasts and does not rotate out with the rest.; Nothing is in a backup that is not in the operational database, so every limit stated for that database applies to it unchanged — except retention itself, where the two exceptions above mean a held set and the statutory copy can outlive the database rows they were taken from..

On whose instructions: Boosthis holds no Google Cloud account and no agreement with Google. The backups are written through the host's App Storage, which is a facility of the hosting recipient above and reaches the bucket on the host's own credentials — so Google Cloud is that recipient's sub-processor, and our instruction runs through it. Google publishes processor terms for its own customers; we are not one, and recording their protections as ours would be borrowing somebody else's contract. Its published terms.

Its own sub-processors: Google publishes a named third-party sub-processor list at its own address, and it is by far the longest of them — a list for a whole cloud platform, most of which has nothing to do with a private storage bucket. So a change on that page is weak evidence about this path specifically, and the watch is honest about what it is: a prompt to go and read, not a finding that something about our backups has moved. Google commits to notice through that page for its own customers. We are not one, so the commitment is not made to us; what reaches us is the page itself, re-read weekly. Its published list.

Onward transfer: What reaches this recipient is a copy of the operational database in a private bucket, colocated by the host with the app's publishing geography — North America today. Google runs a Dammam region inside the Kingdom, so the provider has an in-Kingdom location that this path does not reach; that is recorded as an alternative above rather than as a safeguard here, because it is not one until the path changes. An onward move here is the hosting recipient's to make, and the same term applies as on its own entry: if it means another company starts holding a copy of the database, that company is named on the published recipient page before it begins, on the notice period stated there. The weekly watch reads this page and the hosting recipient's page both, because a change to our backups could show up on either.