Silverpop · Authentication Profile

Silverpop Authentication

Authentication

Silverpop secures its APIs with oauth2 and http across 2 declared security schemes, as derived from its OpenAPI definitions.

Email MarketingMarketing AutomationCampaign ManagementDigital MarketingTransactional EmailSMSCustomer DataContact ManagementMobile PushMarketing Analytics
Methods: oauth2, http Schemes: 2 OAuth flows: API key in:

Security Schemes

OAuth2RefreshToken oauth2
JSessionId http
scheme: session-cookie

Source

Authentication Profile

Raw ↑
generated: '2026-08-13'
method: searched
source: https://developer.goacoustic.com/acoustic-campaign/reference/getting-started-with-oauth
docs:
- https://developer.goacoustic.com/acoustic-campaign/reference/getting-started-with-oauth
- https://developer.goacoustic.com/acoustic-campaign/reference/legacy-authentication-method-jsessionid-user-sessions
- https://developer.goacoustic.com/acoustic-campaign/reference/oauth-token-creation-in-php
- https://developer.goacoustic.com/acoustic-campaign/reference/basics
supersedes: >-
  A derived profile that read a single `BearerAuth` http/bearer scheme out of the
  repository's scaffolded OpenAPI. Upgraded from the provider's own OAuth documentation,
  which is materially richer and contradicts nothing.
summary:
  types:
  - oauth2
  - http
  primary: oauth2
  grants:
  - refresh_token
  scopes: false
  mfa_for_api: false
schemes:
- name: OAuth2RefreshToken
  type: oauth2
  flow: refresh_token
  token_endpoint: https://api-campaign-{region}-{pod}.goacoustic.com/oauth/token
  token_endpoint_note: >-
    The token endpoint is per-tenant. region and pod come from the organization's Campaign
    instance (us-1, us-5, eu-1, …), not from a global host.
  request:
    content_type: application/x-www-form-urlencoded
    parameters:
    - name: grant_type
      required: true
      value: refresh_token
    - name: client_id
      required: true
    - name: client_secret
      required: true
    - name: refresh_token
      required: true
  response:
    access_token: true
    expires_in: 14400
    token_type: bearer
  presentation: 'Authorization: Bearer <access_token>'
  access_token_ttl: 4 hours
  refresh_token_ttl: >-
    Non-expiring. "Refresh tokens do not expire unless the user's access is revoked from
    the Organization's Settings for that application."
  reuse: >-
    Access tokens are reusable within their window and the provider explicitly wants them
    reused — "OAuth access tokens allow calls to re-use existing tokens if they are still
    valid so that a new token does not have to be generated with every call." Recommended
    refresh cadence is every 3 hours.
  provisioning:
    client_credentials: >-
      Org Admin -> Organization Settings -> Application Account Access -> Add Application.
      Returns a Client Id and Client Secret, scoped to an APPLICATION.
    refresh_token: >-
      Org Admin -> Add Account Access, binding an Application to a user Account. The token
      is EMAILED to the user who created the request and to the principal org admin. It is
      never returned by an API call.
  revocation: >-
    Per refresh token, from Organization Settings. Deleting the token ends a third party's
    access without rotating a shared password — the provider names this as the main reason
    to prefer OAuth over the legacy session method.
  scopes: []
  scopes_note: >-
    There is no scope or consent model. Authorization is inherited wholesale from the
    Campaign permission set of the user the refresh token is bound to — "we connect users
    to the application so that we can apply our existing built-in security model as is
    defined for that user." The practical consequence for an agent integration is that a
    token cannot be narrowed: whatever that human can do in the UI, including PurgeData
    and ScheduleMailing, the token can do over the API. No scopes/ artifact was written
    because there are no scopes to enumerate.
  sources:
  - https://developer.goacoustic.com/acoustic-campaign/reference/getting-started-with-oauth
- name: JSessionId
  type: http
  scheme: session-cookie
  status: legacy
  description: >-
    The original session-based authentication for the XML API. Log in, receive a
    JSESSIONID, pass it on subsequent calls, and call the Logout API to release the
    session.
  constraints:
  - No more than 20 active login sessions per organization at any time.
  - >-
    Sessions not terminated with the Logout API can remain active for several minutes and
    block creation of new sessions.
  deprecation: >-
    Filed by the provider under "Legacy authentication method" with the instruction that
    "all users of the Acoustic Campaign XML API are strongly encouraged to use OAuth 2.0
    authentication." No retirement date published. See lifecycle/silverpop-lifecycle.yml.
  sources:
  - https://developer.goacoustic.com/acoustic-campaign/reference/legacy-authentication-method-jsessionid-user-sessions
  - https://developer.goacoustic.com/acoustic-campaign/reference/basics
guidance:
- >-
  Never embed these credentials in an app distributed to end-user devices. The provider
  states the consequences directly: credentials exposed to attackers, no control over the
  10-concurrent-request org limit, and loss of API logs for troubleshooting. Put a service
  you control between the app and this API.
- >-
  Because there are no scopes, treat the refresh token as a full-privilege credential for
  the bound user and gate destructive operations in your own layer. The recommended
  execution contracts are in agentic-access/silverpop-agentic-access.yml.