RevSure Integration Access and Permissions

What RevSure connects to, what access it requests, and why

1. About this document

This guide lists every system RevSure can connect to, the authentication method used, and the exact permissions requested during setup. It is written for the administrators who approve and provision those connections.

Use it to answer three questions before you connect a system:

• What credentials or consent does RevSure need?

• What data can RevSure read once connected?

• Can RevSure write anything back, and if so, what?

Permission names in this document are the vendor's own scope identifiers, shown exactly as they appear on the consent screen or API application. The plain-language explanation next to each one describes how RevSure uses it.

2. Connection methods

RevSure uses whichever authentication method the target platform supports. Five methods are in use:

Where a platform offers more than one method, the choice is made during onboarding and recorded on the connection.

3. How access is scoped

Read access is the default

Most connections are read-only. RevSure reads campaign, engagement, CRM, and web data to build attribution and pipeline analytics; it does not need to modify those records to do so.

Write-back is explicit and limited

Write-back means RevSure sends data back into a connected platform — for example, writing a propensity score onto a CRM record, or syncing an audience to an ad platform. It is enabled per connection, and only these source integrations support it today:

Every other source connection in this document is read-only. Destination connections (Section 6) are write-by-design: they exist so RevSure can deliver modelled data into your warehouse or CRM.

Access is bounded by the account you connect with

For OAuth and user-delegated connections, RevSure can only see what the authorising user can see. Connecting with a dedicated integration user, restricted to the objects and accounts in scope, is the simplest way to enforce least privilege — and it keeps the connection alive when an individual employee leaves.

Access can be withdrawn at any time

You can revoke a connection from your side without involving RevSure: remove the connected or authorised app in the source platform, revoke the service account's delegation, or rotate the API key. Syncing stops at the next scheduled run and RevSure retains only data already ingested.

4. Source connections at a glance

Systems RevSure reads data from, grouped by category. Full permission lists follow in Section 5.

CRM and marketing automation

Advertising and ABM

Sales engagement and conversation intelligence

Web, product and analytics

Collaboration and productivity

Data warehouses and databases

5. Permission detail by integration

This section covers every integration that presents a consent screen or a defined permission set. Integrations authenticated with an API key or database credentials are covered in Section 5.7.

5.1 CRM and marketing automation

Salesforce

Authentication: OAuth 2.0 against a Salesforce connected app.

Data direction: Read, plus optional write-back of RevSure-generated fields.

Permissions requested

• api — read and write records through the Salesforce APIs, limited to the object, field and record permissions of the authorising user

• refresh_token — keep the connection alive without repeated sign-in

• id — identify the authorising user and org at connection time

Administrator note: Authorise with a dedicated integration user. Grant read on the objects in scope; add field-level edit on the RevSure fields only if write-back is enabled. The same three scopes apply when Salesforce is used as a destination.

HubSpot

Authentication: OAuth 2.0.

Data direction: Read, plus writes limited to list membership and contact/company properties. Standard CRM write-back is not enabled for HubSpot today.

Permissions requested

• crm.objects.contacts.read, crm.objects.companies.read, crm.objects.deals.read, crm.objects.owners.read, crm.objects.line_items.read, crm.objects.marketing_events.read — read CRM records used for funnel and attribution modelling

• crm.schemas.contacts.read, crm.schemas.companies.read, crm.schemas.deals.read — read property definitions so RevSure can map your fields correctly

• crm.lists.read, crm.lists.write — read lists and manage RevSure-generated list membership

• crm.objects.contacts.write, crm.objects.companies.write, crm.schemas.contacts.write — create RevSure properties and populate them on contact and company records

• forms, content, sales-email-read, business-intelligence, e-commerce — read form submissions, page and content engagement, marketing email activity, and campaign performance

• oauth — required by HubSpot for any OAuth connection

Administrator note: HubSpot grants scopes at the application level, so all of the above appear on the install screen even where a given feature is not in use.

Salesforce Pardot (Account Engagement)

Authentication: OAuth 2.0 against Salesforce.

Data direction: Read.

Permissions requested

• api — access Salesforce APIs as the authorising user

• refresh_token — maintain the connection

• pardot_api — read Pardot prospect, list and campaign data

Marketo

Authentication: REST API credentials (client ID and secret) issued to an API-only user.

Data direction: Read, plus write-back.

Permissions requested

• No OAuth consent screen — access is entirely governed by the role assigned to the API-only user.

Administrator note: Grant read access to leads, activities and assets. Add the corresponding write permissions only if write-back is enabled.

Microsoft Dynamics 365

Authentication: OAuth 2.0 against Microsoft Entra ID.

Data direction: Read.

Permissions requested

• openid — identify the authorising user

• offline_access — maintain the connection without repeated sign-in

• <your Dynamics organisation URL>/user_impersonation — access Dynamics on behalf of the authorising user

Administrator note: Because access is delegated, RevSure sees exactly what the authorising user's Dynamics security roles allow — no more.

5.2 Advertising and ABM

Google Ads

Authentication: OAuth 2.0 against a Google account with access to the Ads account or MCC.

Data direction: Read, plus write-back of conversion actions and Customer Match audiences.

Permissions requested

• https://www.googleapis.com/auth/adwords — read campaign, cost and performance data; create and update conversion actions and audiences when write-back is enabled

• profile, email — identify the authorising Google account

LinkedIn

Authentication: OAuth 2.0.

Data direction: Read, plus write of conversion events and matched audiences.

Permissions requested

• r_liteprofile, r_emailaddress — identify the authorising user

• r_ads, r_ads_reporting — read ad accounts, campaigns and performance reporting

• r_organization_social — read organic company page activity

• r_marketing_leadgen_automation — read Lead Gen Form submissions

• rw_conversions — send offline conversion events back to LinkedIn

• rw_dmp_segments — create and update matched audience segments

• rw_organization_admin — read company page administration data

Administrator note: The authorising user must be an administrator on both the ad account and the company page. Lead-gen and page-admin access are verified at connection time; without them, those features are unavailable.

Facebook / Meta Ads

Authentication: OAuth 2.0.

Data direction: Read, plus write-back.

Permissions requested

• ads_read — read campaign, spend and performance data

• ads_management — write conversions and manage custom audiences — required for write-back

• business_management — read the business assets the ad accounts belong to

• email — identify the authorising user

Microsoft Ads

Authentication: OAuth 2.0.

Data direction: Read, plus write-back of conversion data.

Permissions requested

• openid — identify the authorising user

• offline_access — maintain the connection

• https://ads.microsoft.com/msads.manage — read reporting and, where write-back is enabled, submit conversions

X (Twitter) Ads

Authentication: OAuth 2.0.

Data direction: Read, with write capability present on the token.

Permissions requested

• tweet.read — read post and campaign content

• users.read — read account details

• offline.access — maintain the connection

• tweet.write — requested as part of X's standard ads scope set

Reddit Ads

Authentication: OAuth 2.0.

Data direction: Read.

Permissions requested

• read — read account and campaign metadata

• adsread — read ad performance reporting

RollWorks

Authentication: OAuth 2.0.

Data direction: Read.

Permissions requested

• all — RollWorks issues a single scope covering its API; RevSure uses it to read campaign and audience reporting

Sendoso

Authentication: OAuth 2.0.

Data direction: Read.

Permissions requested

• public — read send, campaign and recipient activity

5.3 Sales engagement and conversation intelligence

Outreach

Authentication: OAuth 2.0.

Data direction: Read, plus write-back.

Permissions requested

• prospects.read, accounts.read, opportunities.read — read the records RevSure maps to leads, accounts and opportunities

• sequences.read, sequenceStates.read, sequenceSteps.read — read sequence definitions and where each prospect sits within them

• tasks.read, calls.read, callDispositions.read, mailings.read — read outbound activity and outcomes

• users.read, roles.read, teams.read — attribute activity to the right rep and team

Administrator note: Write-back relies on additional permissions granted on the Outreach application; these are configured with RevSure during onboarding.

Apollo

Authentication: OAuth 2.0.

Data direction: Read.

Permissions requested

• accounts_search, account_stages_list — read accounts and their stages

• contacts_search — read contacts

• opportunity_read, opportunities_list, opportunity_stages_list — read opportunities and pipeline stages

• emailer_campaigns_search, email_accounts_list — read outbound campaign and sending-account activity

• tasks_list — read task activity

Drift

Authentication: OAuth 2.0.

Data direction: Read.

Permissions requested

• conversation_read, event_read — read chat conversations and events

• contact_read, account_read — match conversations to people and companies

• playbook_read — read the playbook that triggered a conversation

• user_read, team_read — attribute conversations to reps and teams

Salesloft, Gong and Intercom

Authentication: OAuth 2.0.

Data direction: Read.

Permissions requested

• No scopes are selected at connection time. Access is determined by the permissions configured on the RevSure application within each platform, and by the authorising user's own access.

Administrator note: Ask RevSure for the current permission set on these applications if your review requires an itemised list.

5.4 Web, product and analytics

Google Analytics

Authentication: OAuth 2.0.

Data direction: Read.

Permissions requested

• https://www.googleapis.com/auth/analytics.readonly — read GA properties and reporting data

• profile, email — identify the authorising Google account

Google Search Console

Authentication: OAuth 2.0.

Data direction: Read.

Permissions requested

• https://www.googleapis.com/auth/webmasters.readonly — read search performance data for verified properties

• profile, email — identify the authorising Google account

PostHog

Authentication: Personal API key.

Data direction: Read.

Permissions requested

• web_analytics:read — read web analytics data

• query:read — run read queries against your project

• user:read — read user records associated with events

Administrator note: Create the key with exactly these three scopes; no broader project access is required.

RevSure website tracking SDK

Authentication: Client credentials issued by RevSure.

Data direction: Read (first-party collection).

Permissions requested

• A first-party script you deploy on your own domain. It collects page and session activity for visitor identification and journey analysis; it does not access any third-party system.

5.5 Collaboration and productivity

Slack

Authentication: OAuth 2.0. RevSure requests user token scopes rather than bot scopes.

Data direction: Read.

Permissions requested

• channels:read, channels:history — list public channels and read their message history

• groups:read, groups:history — list private channels the authorising user belongs to and read their history

• users:read, users:read.email — resolve message authors to people and match them to CRM records

Administrator note: Because these are user scopes, RevSure can only see channels the authorising user is a member of. Restrict that user's channel membership to control the footprint. These scopes must remain listed under User Token Scopes on the Slack app.

Google Workspace

Authentication: Service account with domain-wide delegation.

Data direction: Read.

Permissions requested

• admin.directory.user.readonly, admin.directory.group.readonly, admin.directory.group.member.readonly — read directory users, groups and membership

• calendar.events.readonly — read calendar events to identify meetings with prospects and customers

• gmail.readonly, gmail.metadata — read mail activity for engagement tracking

Administrator note: These scopes cannot be granted through a consent screen. A super administrator must authorise the RevSure service account client ID in Admin console → Security → Access and data control → API controls → Domain-wide delegation, with exactly this scope list. Delegation can be revoked there at any time. If your policy does not permit Gmail scopes, they can be omitted — mail-derived engagement signals are then unavailable.

Microsoft Outlook

Authentication: Microsoft Entra ID application with tenant administrator consent. The token is requested with the application's default permission set rather than an inline scope list.

Data direction: Read.

Permissions requested

• User.Read.All — list users in the tenant

• Calendars.Read — read calendar events for meeting activity

• Mail.Read — read mail activity for engagement tracking

Administrator note: Because these are application permissions, they apply tenant-wide unless you scope them. Microsoft's application access policies can restrict the application to a specific mail-enabled security group, and RevSure recommends doing so. Confirm the exact permission list against the application shown on your consent screen before approving.

5.6 Data warehouses and databases

Snowflake

Authentication: OAuth 2.0, username and password, or key-pair (RSA) authentication.

Data direction: Read as a source; read and write as a destination.

Permissions requested

• session:role:SYSADMIN — the OAuth scope specifies the Snowflake session role RevSure assumes. SYSADMIN is the default; the role can be set per connection for destination connections

Administrator note: Scopes apply only to OAuth. Username/password and key-pair connections are governed entirely by the grants held by the Snowflake user. If you prefer a dedicated least-privilege role, raise it during onboarding.

Databricks

Authentication: OAuth 2.0 with PKCE.

Data direction: Read as a source; read and write as a destination.

Permissions requested

• sql — run queries against SQL warehouses

• offline_access — maintain the connection without repeated sign-in

Administrator note: Access to specific catalogs, schemas and tables is controlled by Unity Catalog grants on the connecting principal.

Google BigQuery

Authentication: OAuth 2.0.

Data direction: Read as a source; read and write as a destination.

Permissions requested

• https://www.googleapis.com/auth/bigquery — run queries and, for destination connections, write datasets and tables

Administrator note: Restrict the authorising account with IAM roles on the specific project or dataset.

Microsoft Fabric

Authentication: OAuth 2.0.

Data direction: Read as a source; read and write as a destination.

Permissions requested

• Workspace.Read.All, Item.Read.All, Warehouse.Read.All, Lakehouse.Read.All — read workspaces, items, warehouses and lakehouses (source connections)

• Workspace.ReadWrite.All, Item.ReadWrite.All, Warehouse.ReadWrite.All, Lakehouse.ReadWrite.All — the equivalent read-write scopes, requested only for destination connections

• https://database.windows.net/user_impersonation — query the SQL endpoint as the authorising user

• offline_access — maintain the connection

Administrator note: Some connection flows additionally request storage access (https://storage.azure.com/.default) to reach the underlying OneLake storage.

Amazon Redshift and PostgreSQL

Authentication: Direct database credentials.

Data direction: Read as a source; read and write as a destination.

Permissions requested

• No OAuth scopes are involved. Access is governed entirely by the grants held by the database user you provide.

Administrator note: Provide a dedicated user with SELECT on the required schemas only, and allow-list RevSure's egress addresses if your database sits behind a firewall.

5.7 Integrations with no consent screen

These connect with a key or issued credentials rather than OAuth. There is no scope list to review; access is whatever the key or credential itself permits, so create it with the narrowest available permission set.

6. Destination connections

Destinations are systems RevSure writes modelled data into — scores, stages, attribution outputs and enriched records. These connections are write-enabled by design.

Where the same product is used on both sides

If you connect a platform as both a source and a destination, the permissions are identical except where writing requires more:

7. Administrator checklist

Steps that need action on your side before or during connection. Only the items relevant to the integrations you are enabling apply.

All OAuth integrations

1. Decide which account authorises the connection. A dedicated integration user is strongly preferred over an individual's account.

2. Confirm that account has access to the specific ad accounts, CRM objects, workspaces or properties in scope — and nothing beyond them.

3. Review the consent screen against the permission list in Section 5 before approving.

Platform-specific steps

• Google Workspace: authorise the RevSure service account client ID for the listed scopes under Domain-wide delegation. A consent screen will not work for these scopes.

• Microsoft Outlook: a tenant administrator must grant admin consent to the application, and should scope it to a mail-enabled security group using an application access policy.

• Microsoft Dynamics: confirm the security roles held by the authorising user — they define what RevSure can read.

• Slack: the scopes are user token scopes, so review the authorising user's channel membership; that is what determines coverage.

• LinkedIn: the authorising user needs administrator rights on both the ad account and the company page for conversions, matched audiences and Lead Gen Forms to work.

• Snowflake, Redshift and PostgreSQL: create a dedicated user or role with read access limited to the required schemas, and allow-list RevSure's egress addresses if network policies apply.

• Write-back integrations: confirm the target fields or objects with your RevSure team, and grant write access only on those.

8. Credential handling and revoking access

How credentials are stored

[Confirm and insert your standard language on credential storage — encryption at rest, key management, and who within RevSure can access connection credentials.]

Tokens and rotation

For OAuth connections RevSure stores a refresh token rather than a password, and exchanges it for short-lived access tokens. Where a platform supports offline access, that is the scope maintaining the connection. API keys do not expire on their own — rotate them on your normal schedule and update the connection in RevSure when you do.

Revoking access

You can withdraw access at any time, without notifying RevSure first:

• OAuth — remove the connected or authorised application in the source platform.

• Google Workspace — delete the service account client ID from Domain-wide delegation.

• Microsoft — remove the enterprise application or revoke admin consent in Entra ID.

• API keys and database users — revoke the key or disable the user.

Syncing stops at the next scheduled run. Deleting the connection in RevSure also stops collection; for deletion of data already ingested, contact your RevSure team.