salesloft 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-salesloft-api-key

Custody

customer_vault

Injection

header (Authorization)

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.

• salesloft-people (api, pii): https://api.salesloft.com/v2/people
• salesloft-accounts (api, internal): https://api.salesloft.com/v2/accounts
• salesloft-cadences (api, internal): https://api.salesloft.com/v2/cadences
• salesloft-activities (api, pii): https://api.salesloft.com/v2/activity_histories

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. Effect-level tiering: 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 R3 floor; send is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). The review state is draft, not library, for a concrete reason: 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 — 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://developers.salesloft.com/docs/api/people-index/ (retrieved 2026-09-21)
• https://developers.salesloft.com/docs/api/accounts-index/ (retrieved 2026-09-21)
• https://developers.salesloft.com/docs/api/cadences-index/ (retrieved 2026-09-21)
• https://developers.salesloft.com/docs/api/activity-histories-index/ (retrieved 2026-09-21)
• https://developers.salesloft.com/docs/api/cadence-memberships-create/ (retrieved 2026-09-21)
• https://developers.salesloft.com/docs/platform/api-basics/api-key-authentication/ (retrieved 2026-09-21)
• https://developers.salesloft.com/docs/platform/api-basics/oauth-authentication/ (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.