---

name: salesloft-sdk-patterns description: >- Analyze and design a typed Salesloft REST adapter with tenant-bound authentication, endpoint-specific schemas, pagination, errors, and rate metadata. Use when creating or refactoring an integration client. Trigger with "Salesloft SDK patterns", "Salesloft client wrapper", or "typed Salesloft API". argument-hint: "[repository-path] [language]" allowed-tools: Read, Glob, Grep, WebFetch, Write, Edit version: 1.6.0 author: Jeremy Longshore jeremy@intentsolutions.io license: MIT tags:

• saas
• salesloft
• api-client model: inherit effort: medium compatibility: Designed for Claude Code

---

Salesloft Typed REST Adapter

Overview

This skill builds a narrow client around the endpoints an application actually uses. It avoids invented universal schemas, implicit tenant state, and unbounded recursive retries.

Prerequisites

• A repository with an identified HTTP boundary
• Endpoint, scope, request-format, and response-format inventory
• A tenant-to-credential resolver
• Fixture coverage for success and failure envelopes

Tool Discipline

Use Read, Glob, and Grep to inspect package versions, call sites, and generated types. Use WebFetch only for official endpoint contracts. Use Write or Edit after the adapter boundary is confirmed.

Current Contract

• Use https://api.salesloft.com/v2 and documented resource paths; do not force .json onto every path.
• Preserve data, metadata, error, and field-keyed errors as separate typed shapes.
• Pagination and filters are endpoint-specific; page numbers begin at 1 and deep pages consume more rate cost.
• Capture x-ratelimit-endpoint-cost and x-ratelimit-remaining-minute from every response that provides them.
• Use the request content type documented by the endpoint rather than assuming all writes are JSON.

Authentication

Resolve one Bearer credential from the explicit tenant context for every call. Never store a mutable global token or retry with another tenant's credential.

Instructions

1. Inventory exact methods, paths, scopes, query parameters, bodies, and consumed response fields.
2. Define typed success, list metadata, singular error, validation error, and rate-state models.
3. Centralize timeout, Bearer injection, content negotiation, and redacted error capture.
4. Implement an iterative page iterator that stops on metadata.paging.next_page or an empty page.
5. Retry only safe operations or explicitly idempotent application workflows with a bounded attempt budget.
6. Add contract fixtures before migrating callers behind the adapter.

Approval Boundaries

Do not synthesize request fields from examples, automatically fall back to v1, or retry CRM writes without an application idempotency rule and operator approval.

Output

Return endpoint inventory, type boundaries, auth resolver, pagination behavior, retry policy, fixture coverage, and remaining direct calls.

Error Handling

Condition	Response
401	Refresh or reacquire through the configured auth flow once.
403/404	Preserve singular error and verify scope, visibility, and path.
422	Preserve field-keyed errors; do not flatten away field context.
429/5xx	Respect current headers and bounded backoff; surface exhaustion.

Examples

The example below shows the minimum redacted evidence expected from a successful invocation of this operator workflow.

tenant=team-42; endpoint=GET /v2/people; pages=2; rate-cost=2; retries=0

Resources

• Skill-specific official documentation
• Request and response format
• Filtering, paging, and sorting