Marketo package v1.0.0

A Marketo REST API access token for the customer's own instance, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the token. The token is minted by an external process from the custom service's client id and client secret (Admin > Integration > LaunchPoint) against the instance's identity endpoint (/identity/oauth/token, client_credentials grant).

A new access token has a lifespan of 3,600 seconds (one hour) and Marketo issues no refresh token: the external process re-requests a token from the token endpoint, so refresh and rotation ownership sit entirely outside the executor, which injects the stored value verbatim and performs no token lifecycle itself.

Least privilege: the API-only user's role should carry only the permissions the enabled capabilities use — Read-Only Lead, Read-Only Campaign and Read-Only Activity for the reads, and Execute Campaign (which Marketo's permission list defines as 'Request or Schedule a campaign') only if the request-campaign capability is enabled.

Revocation: disabling the custom service or deactivating its API-only user blocks issuance of further tokens, but the reviewed documentation does not state that an already-issued access token is invalidated at that moment — Marketo documents that an access token belongs to a single custom service and that its expiration is independent of tokens for other custom services in the instance — so treat an outstanding token as potentially valid for the remainder of its 3,600-second lifespan after disablement, and time disablement so that residual validity window is acceptable; an expired token fails closed.

Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

The endpoint host 'marketo-instance.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): Marketo's REST API host is unique per instance and is visible in Admin > Integration > Web Services (the retrieved authentication documentation confirms the instance's REST API and identity URLs appear there), so substitute the customer's own REST API host before enabling, in the endpoints, the resource locators and the egress allowlist — the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step.

Allowlisting the reserved .invalid host does not make an unsubstituted pack safe: the reserved host resolves nowhere, but that is a fail-closed default, not a review substitute — a reviewer must still bind the real host deliberately. CAMPAIGN_ID in the request-campaign path is a placeholder the deployment binds to a concrete, reviewed trigger campaign before enabling. Reads are registered against the collection endpoints only: single-record reads (GET /rest/v1/lead/{id}.json, GET /rest/v1/campaigns/{id}.json, GET /rest/v1/lists/{id}.json) and list-membership reads (GET /rest/v1/lists/{listId}/leads.json) are not registered by this pack.

Paging dependency: the activities read requires a paging token, and paging-token acquisition (GET /rest/v1/activities/pagingtoken.json) is not registered by this pack — it must occur externally, through a separately reviewed process, before the registered activities read can be paged.

Approval classification: marketing automation is send-first.

Request Campaign passes up to 100 named leads through a trigger campaign's flow — the request creates a campaign run for those leads — and a trigger campaign's flow typically sends those people outbound email (not every campaign necessarily sends, but the send declaration covers the unrestricted effect against an arbitrary reviewed trigger campaign); a delivered email cannot be recalled — so that capability declares create and send, and send keeps the tier at the minimum R3 tier; send is one of the designated actions requiring human approval.

Documented exclusions — this pack does not register: lead create, update, merge or delete (Sync Leads, Merge Leads, Delete Leads); static-list membership changes (Add to List, Remove from List); Schedule Campaign (POST /rest/v1/campaigns/{id}/schedule.json, which runs a batch campaign against its whole smart list — a second send effect a reviewer should enable separately and deliberately); smart-campaign and email asset management on the /rest/asset/v1 surface; bulk import and export; the identity endpoint (credential issuance is an external process, not a registered capability); and the access_token query-parameter authentication mode — this pack's credential contract uses the Authorization header only and does not register the query-parameter mode.

The activities read returns identified people's behaviour — email opens, clicks, web visits and score changes — so it is classified as pii (personal data) alongside the lead read. Credential review completed on 2026-09-21 for a short-lived access token held in the customer's vault and refreshed by an external process. The requirements and limits are below.

Issuance authority and delegation: the token is minted by the instance's identity endpoint (/identity/oauth/token, client_credentials grant) from a custom service's client id and client secret, which the customer's admin creates in Admin > Integration > LaunchPoint; the token acts as the custom service's API-only user and delegates that user's role permissions.

Scope: Marketo documents no OAuth scope mechanism for this grant — permissions are the API-only user's role, so least privilege is a role carrying only Read-Only Lead, Read-Only Campaign and Read-Only Activity for the reads, plus Execute Campaign ('Request or Schedule a campaign') only if the request-campaign capability is enabled.

Audience: Marketo documents that an access token belongs to a single custom service and that its expiration is independent of tokens for other custom services in the instance; beyond that single-service binding no audience claim is documented. TTL: a new access token has a lifespan of 3,600 seconds (one hour), and Marketo issues no refresh token.

Refresh ownership: the external process re-requests a token from the token endpoint, so refresh and rotation ownership sit entirely outside the executor, which injects the stored value verbatim and performs no token lifecycle itself.

Revocation: disabling the custom service or deactivating its API-only user blocks issuance of further tokens, but the reviewed documentation does not state that an already-issued token is invalidated at that moment — the completed review documents this gap: treat an outstanding token as potentially valid for the remainder of its 3,600-second lifespan, time disablement so that residual window is acceptable, and an expired token fails closed.

Executor access and replay/exposure: the executor reads only the vault reference; the token is a bearer credential replayable within its one-hour TTL, which bounds the replay window.

Alternate access paths: the Marketo UI and other custom services retain access outside this pack with independently expiring tokens, and disabling this service closes only this path. The credential review is complete. Assign accountable owners before deployment.