Welcome to Access Pilot ("we," "our," or "us"), a product of Simple
Technology Solutions, LLC. We help marketing consultants and agencies
request and grant user-level access to clients' marketing platforms
without password sharing. This Privacy Policy explains what we collect,
how we use it, and the choices you have. It applies to our website at
accesspilot.io and the Access Pilot application at accesspilot.io/app.
Information We Collect
Account information (Consultants): when you create
an Access Pilot account, we collect your email address, full name,
and profile photo. If you sign up with email and password, your
password is hashed by our authentication provider (Supabase) and is
never visible to us in plaintext. If you sign up via Google, we
receive only the identity fields described in our Google API
Services disclosure below.
Identity information (Clients): when a Client opens
an access-request link and signs in with their platform identity
(Google, Meta, Microsoft, etc.) to grant access, we receive their
email address and display name from that identity provider so we
can record who granted access and notify the requesting Consultant.
OAuth tokens: when a Client grants access, we
receive a short-lived OAuth access token from the platform. We use
the token only during the active grant session to (1) list the
accounts or assets the Client can share and (2) invite the
Consultant's email as a user on the selected accounts.
We do not persist OAuth access tokens on our servers.
Tokens live in the Client's browser memory for the duration of the
grant flow and are discarded when the session ends.
Platform metadata (transient): to let a Client pick
which assets to share, we read the lists of accounts, properties,
containers, pages, ad accounts, or portals associated with the
Client's connected identity. We read these in real time during the
grant flow and do not cache them server-side after the session ends.
Grant records: when a grant succeeds, we store the
fact of the grant — timestamp, platform, account or asset ID, role
or permission level granted, the requesting Consultant's email, and
the granting Client's email — so the Consultant can see their
request history and so we can audit credit usage. We do not store
the underlying platform data (campaigns, contacts, analytics
reports, page content, etc.).
Workspace and team data: if you create an Agency
workspace, we store the workspace name, optional company logo
(light + dark) and website URL, the list of invited team members
and their roles, and the credit balance assigned to the workspace.
Billing data: credit purchases are processed by
Stripe. We store the Stripe checkout session ID, invoice ID, the
number of credits purchased, the amount paid, and the user who
initiated the purchase. We do not see or store your card number,
CVV, or full card details — Stripe handles those directly.
Two-factor authentication data: if you enable 2FA,
we store a TOTP secret (managed by our authentication provider) and
one-time recovery codes that are hashed at rest using bcrypt. We
never store recovery codes in plaintext.
Referral data: each account has a unique referral
code. If you sign up via someone's referral link, we record the
referrer/referee relationship so we can credit the referral bonus.
Notifications and in-app messages: we store the
notifications shown in your in-app bell (team invites, access
grants, billing events) so they persist across sessions until you
mark them as read.
Aggregate usage data: we collect anonymous
operational metrics, such as the number of access links generated
and the count of successful grants, to monitor service health.
Error and diagnostic data: when the application
encounters an error, we collect a crash report — the error
message and stack trace, your browser type, and the page where
the error occurred — along with, on a sampled basis, a masked
session replay. See "Error Monitoring & Session Replay" below
for what this does and does not capture.
Platform-Specific Data Policies
Google API Services
Access Pilot's use and transfer to any other app of information
received from Google APIs adheres to the
Google API Services User Data Policy, including the Limited Use requirements. See the dedicated
"Google API Services – Privacy & Data Use Disclosure" section
below for per-scope detail.
Meta (Facebook, Instagram)
We use Meta's Login for Business and Marketing APIs to let
Clients grant Consultants access to Meta Business Portfolios,
Pages, Ad Accounts, Catalogs, and Instagram Business accounts.
Depending on the assets the Client chooses to share, we request
permissions including email,
public_profile,
business_management,
pages_show_list,
pages_manage_metadata,
ads_management,
ads_read,
catalog_management, and
instagram_basic. We use this
access only to list the Client's assets so they can select which
to share, and to assign the Consultant as a user on the selected
assets. We do not read or store Meta posts, ad creatives,
conversions, audience data, message content, or business
analytics. Meta access tokens are not persisted on our servers.
Microsoft Advertising
We integrate with the Microsoft Identity Platform and the
Microsoft Advertising API. We request the
https://ads.microsoft.com/msads.manage
scope (plus
openid,
profile,
email, and
offline_access for sign-in) only
to list the Client's Microsoft Advertising customers and accounts
and to invite the Consultant as a user on the selected accounts.
We do not read or store Microsoft Advertising campaign data,
keywords, bids, or reports.
TikTok for Business
We integrate with the TikTok Marketing API to grant access to
TikTok Business Center. We request the
ads.manage and
ads.read scopes only to list the
Client's Business Centers and invite the Consultant as a member.
We do not read or store TikTok ad creatives, audience data, or
reporting.
HubSpot
We integrate with HubSpot OAuth to invite the Consultant as a
user on the Client's HubSpot portal. We request scopes including
oauth,
settings.users.read,
settings.users.write, and the
minimum CRM read scopes that HubSpot requires for portal
discovery. We use this access only to identify the portals the
Client can share and to send a portal invite to the Consultant's
email. We do not read, export, or store contact records, deals,
lists, or other CRM content.
Other platforms (manual access)
For platforms that do not expose an automated user-management
API (including LinkedIn, Pinterest, Shopify, and major CMS
providers such as WordPress, Webflow, and Wix), Access Pilot
generates a deep link to the platform's native admin panel
pre-filled with the Consultant's email. The Client completes the
invitation in the platform's own UI. We do not receive an OAuth
token, asset list, or any platform data for these manual flows.
How We Use Your Information
We use the information we collect to:
Operate the core service — generating access-request links,
presenting Clients with the assets they can share, and inviting
Consultants as users on selected platforms.
Authenticate Consultants (email + password or social sign-in) and
optionally enforce two-factor authentication.
Manage Agency workspaces, including team membership, role
assignment, shared credit balances, and white-labeling.
Process credit purchases via Stripe and record the resulting
transactions for billing history.
Send transactional emails — access-request links to Clients,
grant-confirmation and team-invite notifications to Consultants,
welcome emails, and referral-bonus confirmations — via our email
provider (Resend).
Operate the referral program by attributing referrals to the
correct referrer and crediting referral bonuses.
Detect and prevent fraud, abuse, and misuse of the service.
Communicate with you about service changes, security advisories,
and (for Consultants who have not opted out) occasional product
updates. We do not sell your personal information.
Data Security
We rely on industry-standard security controls. All traffic between
your browser and our infrastructure is encrypted in transit using
TLS. Our application database (Supabase Postgres) enforces row-level
security so that workspace data is only visible to members of the
correct workspace. OAuth access tokens are handled in the Client's
browser during the active grant session and are not persisted on
our servers. Passwords are hashed by our authentication provider and
are never visible to us in plaintext. Two-factor-authentication
recovery codes are stored as bcrypt hashes. Stripe handles payment
card data directly under PCI DSS — we never see card numbers or CVVs.
No system can be guaranteed 100% secure; if we become aware of a
breach that affects your personal data, we will notify affected
users in accordance with applicable law. We also monitor the
application for errors using a third-party error-monitoring tool
configured to mask all on-screen text, form inputs, and media in
session replays and to not collect your IP address; see "Error
Monitoring & Session Replay" below.
Google API Services – Privacy & Data Use Disclosure
Access Pilot ("we," "our," or "us") uses Google OAuth 2.0 to
authenticate users and facilitate secure access granting. Below is
a detailed explanation of each permission we request and how we
use the associated data.
Access Pilot's use and transfer to any other app of information
received from Google APIs adheres to the
Google API Services User Data Policy, including the Limited Use requirements.
Access Pilot serves two distinct user roles, Consultants and
Clients, and handles their data differently.
Consultants may sign in to Access Pilot using Google Single
Sign-On. When doing so, we collect:
Email address – used for account creation, login, transactional
notifications (e.g., when a Client grants access), and may in
the future be used for promotional or advertising
communications. Consultants can opt out of promotional emails at
any time.
Full name – used to create and display the Consultant's profile
within the application and in communications with Clients.
Profile photo – used to personalize the Consultant's profile
within the application and may be displayed to Clients during
the access-granting process.
Clients (Access Grantors)
Clients authenticate with their Google account when they open an
Access Request Link sent by a Consultant. During this
authentication, we collect:
Email address – used solely to identify the person granting
access. When access is successfully granted, the Client's email
address is included in the notification sent to the Consultant
so they can confirm who provided the permissions.
Basic profile information (name) – used only to personalize the
access-granting interface during the active session.
We do not use Client email addresses for marketing, advertising,
analytics, or any purpose other than identifying the grantor to
the Consultant. Client identity data is not stored beyond what is
necessary to complete and record the access-granting transaction.
2. Google Analytics
These scopes are requested from Clients only during the
access-granting process. Consultants do not authenticate with
these scopes.
https://www.googleapis.com/auth/analytics.readonly
– "See and download your Google Analytics data." We use this
read-only permission exclusively to retrieve the list of Google
Analytics accounts and properties associated with the Client's
Google account, so the Client can select which ones to share
with the Consultant. We do not download, store, or analyze any
Analytics reporting data.
https://www.googleapis.com/auth/analytics.manage.users
– "Manage Google Analytics Account users by email address." We
use this permission exclusively to add the Consultant's email
address as a user on the Google Analytics properties the Client
selects. We do not modify, remove, or otherwise manage any other
user permissions on the Client's account.
3. Google Ads
These scopes are requested from Clients only during the
access-granting process. Consultants do not authenticate with
these scopes.
https://www.googleapis.com/auth/adwords
– "See, edit, create, and delete your Google Ads accounts and
data." We use this permission exclusively to (a) list all Google
Ads accounts accessible to the Client's Google account so the
Client can select which ones to share, and (b) grant the
Consultant access to the selected Google Ads accounts via the
Google Ads API. We do not view, edit, create, or delete any
Google Ads campaigns, billing information, or reporting data. No
ads data is read, stored, or transmitted beyond what is
necessary to list accounts and grant user access.
4. Google Tag Manager
These scopes are requested from Clients only during the
access-granting process. Consultants do not authenticate with
these scopes.
https://www.googleapis.com/auth/tagmanager.readonly
– "View your Google Tag Manager container and its
subcomponents." We use this read-only permission exclusively to
retrieve the list of Google Tag Manager accounts and containers
associated with the Client's Google account, so the Client can
select which ones to share with the Consultant. We do not read
or store any tag configurations, triggers, variables, or other
container data.
https://www.googleapis.com/auth/tagmanager.manage.users
– "Manage user permissions of your Google Tag Manager account
and container." We use this permission exclusively to add the
Consultant's email address as a user on the Google Tag Manager
accounts and containers the Client selects. We do not modify,
remove, or otherwise manage any other user permissions on the
Client's account.
Data Handling Principles
No persistent storage of tokens. OAuth access tokens are used
during the Client's active session to perform the
access-granting actions. They are not permanently stored on our
servers.
No secondary use. Data obtained through Google API scopes is
used only for the purposes described above and is never used for
advertising, data mining, or sold to third parties.
No data retention beyond necessity. The data is used only during
the Client’s active session. Lists of accounts and properties
are retrieved in real time and are not cached or stored after
the session ends.
Minimal scope usage. We request only the permissions strictly
necessary to list assets and grant user access. We do not
request broader scopes than needed.
Revoking Access
You can revoke Access Pilot's access to your Google account at any
time by visiting your
Google Account Permissions page
and removing Access Pilot from the list of connected applications.
Meta Platform – Privacy & Data Use Disclosure
Access Pilot ("we," "our," or "us") uses Meta's Facebook Login
for Business and the Meta Graph and Marketing APIs to let Clients
grant Consultants user-level access to their Meta business assets
— Business Portfolios, Facebook Pages, Ad Accounts, Pixels
(datasets), Product Catalogs, and Instagram Business accounts —
without sharing passwords. Below is a detailed explanation of each
permission we request and how we use the associated data.
Our use of information received from the Meta APIs adheres to the
Meta Platform Terms
and
Developer Policies, including the data-minimization and limited-use requirements.
We use Meta data only to list the Client's assets so they can
choose what to share, and to assign the Consultant as a user on
the selected assets. We do not read, export, or store the
underlying business content (posts, ad creatives, conversions,
audiences, message content, catalog items, or analytics).
These permissions are requested from Clients only during the
access-granting process. Consultants sign in to Access Pilot with
Google or email and never authenticate with these Meta
permissions. Meta access tokens are used only during the Client's
active grant session and are not persisted on our servers.
1. Identity (email,
public_profile)
email – "Access your
primary email address." We use the Client's email address solely
to identify the person granting access. When access is
successfully granted, the Client's email is included in the
notification sent to the requesting Consultant so they can
confirm who provided the permissions. We do not use Client email
addresses for marketing, advertising, or analytics.
public_profile – "Access
your public profile." Granted by default with Facebook Login, we
use the Client's name and profile picture only to personalize the
access-granting interface during the active session and to
display who granted access. We do not store the Client's profile
beyond what is necessary to record the grant.
2. Business Portfolios
(business_management)
business_management –
"Manage your business." We use this permission exclusively to
(a) list the Business Portfolios (Business Manager accounts) the
Client can administer so they can select which to share, and
(b) assign the requesting Consultant's email as a user on the
selected Business Portfolios and their child assets. We do not
create, delete, or otherwise modify the Client's business
settings, finances, or any user permissions other than adding
the Consultant.
pages_show_list – "Show a
list of the Pages you manage." We use this read-only permission
exclusively to retrieve the list of Facebook Pages associated
with the Client's account so the Client can select which Pages
to share with the Consultant.
pages_manage_metadata –
"Manage accounts, settings, and webhooks for a Page." We use
this permission exclusively to assign the Consultant a role on
the Pages the Client selects. We do not publish posts, read
inbox messages, change Page content, or subscribe to Page
webhooks for any other purpose.
4. Ad Accounts, Pixels & Catalogs
(ads_management,
ads_read,
catalog_management)
ads_read – "Read your ad
accounts' data." We use this read-only permission exclusively to
list the Ad Accounts and associated Pixels (datasets) the Client
can share. We do not read or store campaigns, ad creatives,
conversions, audiences, or reporting.
ads_management – "Manage
your ads." We use this permission exclusively to add the
Consultant as a user on the Ad Accounts and Pixels the Client
selects. We do not create, edit, pause, or delete campaigns,
ad sets, ads, or billing settings.
catalog_management –
"Manage your product catalogs." We use this permission
exclusively to list the Client's Product Catalogs and assign the
Consultant access to the catalogs the Client selects. We do not
read, edit, or store catalog items, feeds, or commerce data.
5. Instagram
(instagram_basic)
instagram_basic – "Access
profile and posts from the Instagram account connected to your
Page." We use this read-only permission exclusively to identify
the Instagram Business accounts linked to the Client's Pages or
Business Portfolios so they can be included when the Client
grants the Consultant access. We do not read, store, or analyze
Instagram media, comments, insights, or message content.
Data Handling Principles
No persistent storage of tokens. Meta OAuth access tokens are
used during the Client's active session to perform the
access-granting actions. They are not permanently stored on our
servers.
No secondary use. Data obtained through Meta permissions is used
only for the purposes described above and is never used for
advertising, data mining, or sold to third parties.
No data retention beyond necessity. Lists of Business
Portfolios, Pages, Ad Accounts, Catalogs, and Instagram accounts
are retrieved in real time and are not cached or stored after
the session ends.
Minimal, least-privilege permissions. We request only the
permissions strictly necessary to list the assets the Client
chose and grant the Consultant user access, selecting the
smallest permission bundle that supports the requested assets.
We do not request broader permissions than needed.
Revoking Access
You can revoke Access Pilot's access to your Meta account at any
time by visiting your Facebook
Business Integrations settings
and removing Access Pilot from the list of connected business
tools. Removing a Consultant's user access to a specific asset is
done from the asset's settings in Meta Business Manager.
Data Retention & Deletion
We retain data only as long as it serves a legitimate
operational purpose:
OAuth access tokens: never persisted to
our servers; held in browser memory only for the active
grant session, and discarded when the session ends.
Platform asset lists (accounts,
properties, pages, etc.) read during a grant flow are
fetched in real time and are not cached server-side.
Grant records and transactions are
retained for as long as your account is active so you
can audit your request history and credit ledger. You
can request deletion of historical grant records by
contacting us (see "Your Privacy Rights" below).
Agency workspaces: when an Agency owner
disbands a workspace, the workspace record and all of
its associated team memberships, access requests, and
transactions are permanently deleted from our database.
Revoked team members: when a member is
removed from an Agency, their membership row is marked
revoked; their personal Access Pilot account is not
deleted and they retain access to their Personal
workspace.
Payment records: we retain transaction
metadata (Stripe session and invoice IDs, amounts,
dates) for as long as required by applicable
tax/accounting law.
You can revoke Access Pilot's access to any connected
third-party platform at any time directly from that
platform's settings. Doing so does not delete your Access
Pilot account; to request full account deletion, see
"Your Privacy Rights" below.
Cookies & Local Storage
Access Pilot uses browser local storage and session
storage (rather than tracking cookies) to keep the
application working. The values we store on your device
include:
Authentication session (local storage):
a session token issued by our authentication provider
so you stay signed in between visits.
Workspace preferences (local storage):
your active brand, the last workspace you switched
away from (used during Agency disband recovery), and
referral codes captured at signup.
White-label configuration (local storage):
an optional custom Google OAuth client ID and proxy URL
if you have set up a white-labeled flow.
OAuth handoff state (session storage):
during a Client grant flow, short-lived values such as
the return URL and the in-flight Meta access token, so
the OAuth popup can return you to the right place.
These values live only in the Client's own browser — they
are not transmitted to or stored on Access Pilot's servers
— and are cleared when the browser tab closes.
Stripe Checkout (Stripe-owned cookies):
when you check out, Stripe sets its own cookies on its
checkout domain to prevent payment fraud. Those cookies
are governed by
Stripe's privacy policy.
We use Google Tag Manager and Simple CRM in two distinct
ways. On our public marketing pages (including this
Privacy Policy page) we load Google Tag Manager and the
Simple CRM embed script to measure inbound traffic and
the effectiveness of our marketing campaigns. Inside the
Access Pilot application we load Google Tag Manager on
the sign-in page and the Consultant dashboard to
understand how Consultants use the product so we can
improve it; once loaded, Google Tag Manager remains
active as a signed-in Consultant navigates within the
application. The Consultant dashboard also exposes a
"report a bug / request a platform" form whose
submissions are sent to Simple CRM only when you submit
them.
We do not load Google Tag Manager, the Simple CRM
tracking script, Google Analytics, or any other
third-party tracking or advertising tag on the
access-request page that Clients open to grant access
(accesspilot.io/app/request?requestId=...), and we
do not load Google Analytics or any third-party
advertising pixel anywhere else in the application
either. You can block any of these tags with standard
browser tracking-protection settings or a content
blocker; blocking Simple CRM will prevent the in-app
feedback form from sending your message, but Access
Pilot will otherwise continue to work. The one third-party
script that does run application-wide — including on the
access-request page — is our error-monitoring tool (Sentry),
which we use purely to keep the Service reliable, not for
analytics or advertising; see "Error Monitoring & Session
Replay" below for exactly what it does and does not capture.
Error Monitoring & Session Replay
To keep Access Pilot reliable, we use
Sentry
(operated by Functional Software, Inc.) to monitor the application
for errors and performance problems. Sentry runs across the
application, including the access-request page that Clients open to
grant access. We use it solely for reliability and debugging — it
is not analytics or advertising, and we do not use
it to build a marketing profile of you.
When the application encounters a problem, Sentry receives:
Error reports: the error message and stack
trace, your browser type, and the page or route where the error
occurred.
Performance data: navigation and page-load
timing. Routes are recorded in a generic form (for example,
/accept/:requestId) rather than
with the specific identifiers in your address bar.
Masked session replays (sampled): a
reconstruction of what happened in the browser so we can
reproduce a bug.
All on-screen text and form input values are masked and all
media is blocked
— we see layout and interactions, not the content you typed or
viewed.
Sentry does not receive your IP address or request
headers. We do not attach your email address or name to these
reports; where we need to correlate an error to an account we use
an opaque internal identifier, not your email. You can block Sentry
with standard browser tracking-protection settings or a content
blocker; the application will otherwise continue to work.
Your Privacy Rights
Depending on where you live, you may have the following
rights regarding your personal information:
Access: request a copy of the personal
data we hold about you.
Correction: ask us to fix inaccurate
or incomplete information.
Deletion: ask us to delete your
account and personal data, subject to legal retention
requirements (e.g., tax records on completed
transactions).
Portability: request your data in a
portable format.
Objection / restriction: ask us to
stop or limit certain processing.
Withdraw consent: where processing is
based on consent, withdraw that consent at any time.
Opt out of "sale" or "sharing": we do
not sell personal information, and we do not share it
for cross-context behavioral advertising. California
residents have additional rights under the CCPA/CPRA;
EU/EEA and UK residents have additional rights under
the GDPR and UK GDPR.
To exercise any of these rights, email
privacy@accesspilot.io
from the address associated with your account. We will
verify your identity and respond within the timeframe
required by applicable law.
Children's Privacy & International Transfers
Access Pilot is a business tool intended for use by
professionals. It is not directed to children, and we do
not knowingly collect personal information from anyone
under the age required to consent to online services in
their jurisdiction. If you believe a child has provided
us personal information, please contact us and we will
delete it.
Our infrastructure providers (Supabase, Stripe, Resend,
and the third-party platforms you connect, such as
Google, Meta, Microsoft, TikTok, and HubSpot) may
process your data outside your country of residence.
Where required, we rely on Standard Contractual Clauses
and equivalent safeguards to protect cross-border
transfers.
Third-Party Services
We rely on a small number of vetted sub-processors to run
Access Pilot. They receive only the data necessary to
perform their function on our behalf:
Supabase — application database,
authentication, and serverless edge functions. Hosts
account profiles, workspace data, grant records, and
transactions.
Stripe — payment processing for credit
purchases. Stripe receives your name, billing email,
and payment details directly; we receive only
non-sensitive metadata (session ID, invoice ID,
amount, currency).
Resend — delivery of transactional
emails (access-request links to Clients,
grant-confirmation and team-invite notifications,
welcome emails, referral confirmations). Receives only
the recipient address and the message contents.
Simple CRM — used in two ways: as a
marketing-attribution script embedded on our public
marketing pages, and as the destination of the "report
a bug / request a platform" feedback form submissions
from inside the Consultant dashboard. Not loaded on
the access-request page that Clients open to grant
access. See "Cookies & Local Storage" above for
opt-out guidance.
Sentry (Functional Software, Inc.) —
application error monitoring and session replay. Receives
JavaScript error reports, stack traces, performance traces, and
sampled session replays in which all text, inputs, and media are
masked. Does not receive your IP address, email, or any unmasked
text or input values.
Third-party platforms — Google, Meta,
Microsoft, TikTok, HubSpot, and the other platforms
listed in the application. These are the platforms you
explicitly choose to grant access to; their use of
your data is governed by their own privacy policies.
Changes to This Policy
We may update this Privacy Policy as the service evolves
or as required by law. When we make material changes, we
will update the "Last Updated" date at the top of this
page and, where appropriate, notify Consultants by email
or in-app message. Continued use of Access Pilot after a
revision takes effect constitutes acceptance of the
revised policy.
Contact Us
If you have any questions about this Privacy Policy, please
contact us at
privacy@accesspilot.io