Outreach package v1.0.0

An Outreach OAuth 2.0 access token (authorization-code flow against an Outreach app configured by the customer), 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.

Access tokens live for 2 hours (expires_in 7200) and refresh tokens for 14 days, and refresh tokens rotate: Outreach issues a new refresh token with each new access token, a replaced refresh token must not be persisted, and a user/application pair can hold at most 100 refresh tokens at a time.

Refresh and rotation ownership sit entirely with an external process; the executor injects the stored value verbatim and performs no token lifecycle itself.

Scopes are period-separated strings of the form <resource>.<read|write|delete|all> and are not additive — prospects.write does not grant prospects.read — so request exactly the scopes the enabled capabilities need: prospects.read, mailings.read, tasks.read and events.read for the reads, and sequenceStates.write only if the enrollment capability is enabled — sequenceStates.all (which adds delete) is not the least-privilege recommendation where sequenceStates.write suffices and is not offered as an interchangeable alternative. OAuth scopes are the front gate only; the customer's governance permissions still bound what the token can touch.

Revocation: tokens are revoked when the customer revokes the authorization grant, and an expired or revoked value 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 api.outreach.io is Outreach's real shared API host and stays real; there is no per-customer host to substitute. The API speaks JSON:API: write requests must carry Content-Type application/vnd.api+json, and reads page with the JSON:API pagination parameters. Reads are registered against collection endpoints that Outreach's own guide documentation shows explicitly; single-record reads (GET /api/v2/prospects/{id} and the other by-id paths) are not registered by this pack.

Operation-specific evidence: the sequence-states create is shown in the guide's 'Add Prospects to Sequences' section (POST /api/v2/sequenceStates, automation begins, state set to active), the tasks read in 'Discover Open Tasks' (GET /api/v2/tasks with state and owner filters), and the events read in 'Download Event Activity' (GET /api/v2/events?sort=-updatedAt); the mailings collection appears in the guide as a documented related-resource link (GET /api/v2/mailings?filter[template][id]=1 in the templates section) and in the platform-statistics discussion, while the guide's dedicated mailings section is marked 'More information coming soon' — mailings.read therefore rests on that related-link evidence rather than a worked collection example, and a reviewer who renders the interactive API reference should confirm it before enabling.

Documented exclusions — this pack does not register: account reads and sequence reads, because those collection GETs are enumerated only in Outreach's interactive API reference, a JavaScript application whose endpoint pages could not be rendered for this review — per the pack standard, fewer capabilities are registered rather than padding the pack from third-party sources, and a reviewer who renders the reference can add them; prospect, account, sequence, sequence-step, ruleset and template creation or update; the sequence-state finish, pause and resume actions; one-off mailing scheduling (Outreach's guide marks that section's documentation as not yet published); compliance deletion requests (permanent CCPA/GDPR deletes of a prospect or individual, processed asynchronously); call logging; user invitation (which by default sends the invitee an email); and webhooks.

Approval classification: sales engagement is send-first. Creating a sequence state enrolls a prospect in a sequence and Outreach documents that the sequence's automation begins immediately with the state set to active; sequence steps include auto_email, which sends the enrolled person outbound email from the referenced mailbox without further human action — a delivered email cannot be recalled — so the 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.

The events read returns the platform's event stream (for example prospect_updated), which records the activity of named users and references individual prospects, so it is classified as pii (personal data); tasks reference prospects and carry user notes, and mailings carry message bodies and recipient addresses, so those reads are pii as well. Credential review completed on 2026-09-21 for a user-granted OAuth access token held in the customer's vault and refreshed by an external process. The requirements and limits are below.

Issuance authority and delegation: tokens are minted by Outreach's token endpoint through the authorization-code flow against an Outreach app the customer configures, and the token acts on the granting user's behalf; the customer's governance permissions still bound what the token can touch beyond the OAuth scopes.

Scope: scopes are period-separated strings of the form <resource>.<read|write|delete|all> and are not additive — prospects.write does not grant prospects.read — so the grant is exactly prospects.read, mailings.read, tasks.read and events.read for the reads, plus sequenceStates.write only if the enrollment capability is enabled; sequenceStates.all (which adds delete) is deliberately not requested.

Audience: no audience mechanism is documented — the bearer value authorizes against api.outreach.io, and audience binding beyond that is not established. TTL: access tokens live for 2 hours (expires_in 7200) and refresh tokens for 14 days, and a user/application pair can hold at most 100 refresh tokens at a time.

Refresh ownership: refresh and rotation ownership sit entirely with an external process; Outreach issues a new refresh token with each new access token and a replaced refresh token must not be persisted, so the process must always store the newest value; the executor injects the stored value verbatim and performs no token lifecycle itself.

Revocation: tokens are revoked when the customer revokes the authorization grant, and an expired or revoked value fails closed; the reviewed documentation describes grant-level revocation and enumerates no token-revocation endpoint, so none is claimed. Executor access and replay/exposure: the executor reads only the vault reference; the token is a bearer credential replayable within its two-hour TTL, and refresh rotation plus the 14-day refresh-token lifetime bound a stolen refresh token's window.

Alternate access paths: the Outreach UI and other applications retain access outside this pack, and revoking this grant closes only this path. The credential review is complete. Assign accountable owners before deployment.