Per-app policies

Why every app has its own policy

A site-wide privacy policy describes a company. An app-store reviewer is not assessing a company, they are assessing one app: which scopes it asks for at install, which records those scopes expose, what the app does with each one, how long it keeps them, and what happens on uninstall. A generic policy cannot answer any of that, because it does not know which app you mean.

That is why generic site policies get app submissions rejected. The reviewer opens the privacy URL on the listing, searches for the app name and the scope list, finds neither, and the submission fails on documentation rather than on code.

So we publish two pages per app, at stable URLs that go on the listing itself:

• /legal/apps/<app-slug>/privacy/ names the app, its Platform, every scope it requests with a reason per scope, the retention period per data category, and the platform's own mandatory compliance mechanism.
• /legal/apps/<app-slug>/terms/ covers the licence to use that app, acceptable use, what the merchant is responsible for, termination and uninstall.

Every heading on those pages carries a stable lowercase id, so a listing can deep link straight to the section a store's requirements ask about. We do not rename those ids once published.

The apps and their policy pages

One row per app. Where an app is listed on more than one platform, it gets one row per platform, because the scopes differ.

Example App is a worked example, not a listed app. It exists so a reviewer can see the finished shape of one of these pages, and so whoever writes the next app policy has a filled-in reference rather than a blank template. Nobody can install it and no merchant data has ever passed through it. It must not be submitted to any app store.

When a real app is listed, its row is added here and the app's two URLs go on the store listing. If you are looking for an app that is not in this table, it is not one of ours.

What each app page contains

Every per-app privacy page carries the same sections, in the same order, with the same anchor ids. That is deliberate: a reviewer checking a second app of ours finds the same section in the same place.

what-this-app-is

What the app is, which platform it runs on, and which entity publishes it.

platform-data-and-scopes

A table with one row per scope: the scope name as the platform writes it, what that scope exposes, and the single task in the app that needs it. Named resources, not categories.

merchant-data

What the merchant gives us directly: account, billing, support correspondence, and app logs.

end-customer-data

Personal data about people who are not our customers. This section states plainly that the merchant is the controller of it and we are the processor.

purposes

One purpose per category, in a table, with nothing outside it.

retention

A retention period per category, not one blanket figure. Periods that have not been set are shown as unresolved rather than guessed.

deletion-on-uninstall

What is deleted, when, what is retained, and the reason each retained item is retained.

sub-processors

A link to the one sub-processor list. No app page keeps its own copy.

data-requests

How a merchant files a request, and how an End Customer does. End customers are routed to the merchant first, in wording that is identical on every app page.

encryption

Encryption in transit and at rest, linking the security page for the full control set. We hold no certification and claim none.

platform-compliance

The platform's own mandatory data and deletion mechanism, named, with what the app does when it fires.

version-history

Every change to that page, dated, at the foot of it.

Platform facts are inherited, not restated

An app page describes the app. It does not describe the platform. Rules that a platform places on every app built for it, the mandatory webhooks or deletion callbacks, the deadlines attached to them, and what that platform's API exposes, are written once in the platform annex at /legal/platforms/<platform-slug>/, and the app page links to it.

The reason is maintenance. A platform can change a requirement at any time. If ten app pages each carried their own copy of that requirement, a change would mean ten edits and at least one page left behind saying something that is no longer true. With one annex per platform there is one place to correct, and the app pages keep pointing at it.

So on an app page you will find the scopes that app requests and what that app does when a compliance mechanism fires. You will find the platform's own rule, and the deadline it sets, in the platform annexes.

A claim about what a platform requires today is marked for verification against that platform's live documentation before it is relied on. We do not assert a third party's current rule from memory.

If you are reviewing an app submission

Read the app's own two pages, linked from the table above and from the store listing. Both are indexable, both load without JavaScript, and both work in a frame inside a platform admin.

The three sections most review checklists ask about are:

• Scopes. Section platform-data-and-scopes, one row per scope, with the reason that scope is requested.
• Deletion. Section deletion-on-uninstall, plus section platform-compliance for the platform's own mechanism.
• End customer data. Section end-customer-data, which states who controls it.

Company-level material is elsewhere and applies on top: the site privacy policy, the data processing addendum, the sub-processor list, AI and your data, and security.

If a section you need is not on an app page, tell us and we will add it rather than point you at a general document. Write to hello@aispeedforce.com.

If you are a merchant or an end customer

If you have installed one of our apps, read that app's privacy page for what it reads and what happens when you uninstall, and its terms page for what you are responsible for. Your platform annex under platform annexes covers the rules your platform places on apps generally.

If you are a shopper or a lead of a business that uses one of our apps, that business controls your data and you should contact them first. Each app privacy page carries the same routing wording and explains what we do if you contact us instead.

How a new app page is created

Both pages are stamped from a single pair of templates, so the wording cannot drift between apps. The templates are not served pages and are not listed here as links. Only the app name, slug, platform, scope list, data categories, retention, support address and effective date change per app. Everything else comes from /legal/_data/legal.json and the shared clause library, or stays marked as unresolved on the page.

A per-app page is published before the app is submitted, not after, because the store listing needs the URL at submission.

Contact

Questions about a specific app, including data requests: the support address on that app's page.

Privacy questions: {{TODO: privacy@aispeedforce.com, confirm the mailbox exists}}

Working fallback that reaches us today: hello@aispeedforce.com

Changes to this index

We may update this document. When we do, we change the "Last updated" date and add a row to the version history at the foot of the page. Section anchors are stable and we do not rename them, so a link to a section keeps working.

This index records structural changes: an app added, an app delisted, a platform added for an existing app. Changes to a single app's policy are recorded in that page's own version history.

Version history