Act-On · OAuth Scopes

Act-On OAuth Scopes

OAuth 2.0 derived

Act-On uses OAuth 2.0 but publishes no discrete scopes — access is governed by the grant itself (e.g. client-credentials or role-based authorization) rather than per-scope consent.

This index is generated from the provider’s OpenAPI security definitions (and, where available, its documented scope reference) and refreshes on every APIs.io network build. Browse every provider’s scopes at scopes.apis.io.

CompanyMarketingMarketing AutomationEmail MarketingEmailMarketing TechnologyLead GenerationCampaign ManagementCustomer DataWebhooksAPI
Scopes: 0 Flows: Method: derived

Scopes (0)

Act-On implements OAuth 2.0 but publishes no discrete scopes — access is governed by the grant itself (client-credentials or role-based authorization) rather than per-scope consent.

📄 Provider scope reference:

Source

OAuth Scopes

Raw ↑ 
generated: '2026-08-13'
method: derived
source: openapi/act-on-oauth-openapi.yml + https://developer.act-on.com/reference/api-overview
  + https://developer.act-on.com/reference/userspecs-overview
api: Act-On REST API
summary: >-
  Act-On runs OAuth 2.0 but publishes NO SCOPES. This file records a measured
  absence, not a scope catalog, and no OAuthScopes pointer is emitted in apis.yml on
  the strength of it.
scope_count: 0
scopes: []
schemes:
- name: sec0
  type: oauth2
  source: openapi/act-on-oauth-openapi.yml
  flows: []
  note: >-
    The published securityScheme is literally `{"type":"oauth2","flows":{}}` — no
    authorizationUrl, no tokenUrl, no scopes object. The three grant types Act-On
    documents (password, refresh_token, authorization_code) are described in prose on
    the developer portal, not in the security scheme.
searched:
- url: https://developer.act-on.com/reference/api-overview
  status: 200
  result: no scopes, no permissions reference, no consent screen documentation
- url: https://developer.act-on.com/llms.txt
  status: 200
  result: 161-page documentation index contains no scopes or permissions page
authorization_instead:
  model: account user privileges
  where: set on the Act-On user, in the Act-On UI or at user-creation time
  documented_at: https://developer.act-on.com/reference/userspecs-overview
  privileges:
  - marketingPrivileges:launchPrivilege
  - marketingPrivileges:admin
  - contactLists:create
  - contactLists:delete
  - contactLists:download
  - content:create
  - content:delete
  - programs:create
  - programs:delete
  - accountWideEmail:view
  - accountWideEmail:manage
  note: >-
    These are USER privileges, not OAuth scopes. They bound what a token obtained via
    the password grant for that user can do, but they are never requested, granted,
    returned or introspected through the API — a client cannot ask for least
    privilege, and cannot discover what privilege it actually holds. They are listed
    here as the real authorization surface, deliberately NOT as scopes.
consequence: >-
  There is no downscoping. Any integration authenticating as an administrator holds
  administrator power over the whole account, including irreversible sends and
  deletes. See mcp/act-on-mcp.yml agent_safety_notes.