Salesloft package v1.0.0

A Salesloft customer API key, held in the client's own secret manager. Salesloft provisions API keys in Salesloft Account > Your Applications > API Keys; a key takes the form 'ak' followed by a 64-character hexadecimal string, acts on behalf of the issuing user, and is scoped at creation. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the key.

Issue the key from a dedicated least-privilege integration user with only the scopes the enabled capabilities need — read scopes for people, accounts, cadences and activity_histories for the registered reads, and the cadence-membership write scope only if the create capability is enabled (Salesloft's documentation shows the <resource>:<action> scope naming, for example 'accounts:write calls:read', but the retrieved pages did not enumerate the full scope catalog, so confirm the exact scope names in the Salesloft API-key UI at creation — at least one scope must be selected before a key can be saved); keys function like logins, so the vault reference is the only place the value may live.

Expiry and revocation: Salesloft's API-key documentation documents no expiry for API keys — a key remains valid until it is deleted in Salesloft Account > Your Applications > API Keys, and its scopes can also be narrowed later by editing the key. Where the deployment instead runs the OAuth 2.0 authorization-code flow (the only method Salesloft approves for partner applications): access tokens expire after 7,200 seconds, and on every refresh all older refresh tokens are revoked, so the newest refresh token must always be stored — refresh ownership sits with an external process, and the executor injects the stored value verbatim and performs no token lifecycle itself in either mode. OAuth revocation: the retrieved OAuth documentation documents grant invalidation through its invalid_grant error (an authorization grant that is 'invalid, expired, revoked' can no longer mint tokens) but no explicit access-token revocation endpoint, so revoke the user's authorization grant to block further issuance and refresh, and treat an already-issued access token as valid for at most the remainder of its 7,200-second lifespan.

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.salesloft.com is Salesloft's real shared API host and stays real; the pack pins the v2 base path and there is no per-customer host to substitute. Reads are registered against the collection endpoints only: single-record reads (GET /v2/people/{id}, GET /v2/cadences/{id}, GET /v2/cadence_memberships/{id} and the other by-id paths) are not registered by this pack. The activities read is the activity-history collection (GET /v2/activity_histories), which Salesloft documents as returning the customer's past activities as found on the Salesloft Activity Feed.

Documented exclusions — this pack does not register: person create, update or delete; account create or update; cadence creation, step management, import or deletion; cadence-membership reads (GET /v2/cadence_memberships), updates and deletion, and bulk cadence-membership creation; one-off email sends and call logging under /v2/activities; tasks, notes, meetings, conversations and transcriptions; crm_activities; people data redaction and the other privileged-scope operations; and webhooks.

Approval classification: sales engagement is send-first. Creating a cadence membership adds a named person to a cadence, and a Salesloft cadence is a multi-step outreach sequence — its automated email steps are sent by the platform without further human action, while call, task and other manual steps are only queued for a user to execute — the unrestricted automated-send effect is what governs the tier: 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.

Documentation review is complete. Obtain deployment-specific approval before enabling; live tenant testing remains outstanding. Credential custody was reviewed on 2026-09-21 against this pack's custody model — a scoped customer API key (or, where the deployment runs the OAuth flow, a short-lived access token) held in the customer's vault — with the following findings (the full credential contract is in the credential note).

Issuance authority and delegation: the customer provisions API keys in Salesloft Account > Your Applications > API Keys and OAuth apps under Your Applications > OAuth Applications, and both act on behalf of the issuing or authorizing user, so issuance authority sits with the customer's own admin; OAuth is the only method Salesloft approves for partner applications. Scope: both modes are scoped at creation — at least one scope is required before a key can be saved, and a key's scopes can be narrowed later by editing it; the retrieved pages show the <resource>:<action> scope naming but do not enumerate the full catalog, so exact scope names are confirmed in the UI at creation.

Audience: no audience mechanism is documented — the bearer value authorizes against api.salesloft.com, and audience binding beyond that is not established. TTL: API keys have no documented expiry and remain valid until deleted; OAuth access tokens expire after 7,200 seconds.

Refresh ownership: in OAuth mode every refresh revokes all older refresh tokens, so an external process must always store the newest refresh token, and in API-key mode there is no refresh at all; in both modes the executor injects the stored value verbatim and performs no token lifecycle itself.

Revocation: API keys are revoked by deleting them in the account UI; for OAuth the reviewed documentation establishes grant invalidation only through the invalid_grant error and documents no token-revocation endpoint, so an OAuth revocation endpoint is not established. Executor access and replay/exposure: the executor reads only the vault reference and injects the complete Authorization header value; Salesloft warns that API keys function like logins, so the vault reference is the only place the value may live; both modes are bearer credentials replayable while valid, and OAuth's 7,200-second TTL and forced refresh rotation bound a stolen token's window while an API key has no such bound until deleted.

Alternate access paths: the Salesloft web UI and any other integrations retain access outside this pack, and deleting the key or revoking the grant closes only this path.