marketo v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-marketo-access-token

Custody

customer_vault

Injection

header (Authorization)

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.

• marketo-leads (api, pii): https://marketo-instance.invalid/rest/v1/leads.json
• marketo-campaigns (api, internal): https://marketo-instance.invalid/rest/v1/campaigns.json
• marketo-lists (api, internal): https://marketo-instance.invalid/rest/v1/lists.json
• marketo-activities (api, pii): https://marketo-instance.invalid/rest/v1/activities.json

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 follows the pattern {Munchkin ID}.mktorest.com, so substitute the customer's own REST API host (visible in Admin > Integration > Web Services) 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. Effect-level tiering: 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 R3 floor; send is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). 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, which Marketo is deprecating in favour of the Authorization header. The activities read returns identified people's behaviour — email opens, clicks, web visits and score changes — so it is registered at the pii class alongside the lead read. The review state is draft, not library, for a concrete reason: this pack's custody model — a short-lived access token held in the customer's vault and refreshed by an external process — has not yet been reviewed against the properties the capability-library plan (docs/gtm/CAPABILITY-LIBRARY-PLAN.md §4) gates any authentication mode on: issuance authority and delegation, scope, audience, TTL, refresh ownership, revocation, executor access and bypass paths. That review is unfinished.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://experienceleague.adobe.com/en/docs/marketo-developer/marketo/rest/endpoint-reference (retrieved 2026-09-21)
• https://experienceleague.adobe.com/en/docs/marketo-developer/marketo/rest/assets/smart-campaigns (retrieved 2026-09-21)
• https://experienceleague.adobe.com/en/docs/marketo-developer/marketo/rest/authentication (retrieved 2026-09-21)
• https://developers.marketo.com/rest-api/endpoint-reference/lead-database-endpoint-reference/ (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.