Back to Home

Privacy Policy

Last Updated: 6/3/2026

Introduction

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.

1. Email Address, Profile & Identity (email, profile, openid)

Consultants (Account Holders)

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.

3. Facebook Pages (pages_show_list, pages_manage_metadata)

  • 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