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
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.