---

name: salesloft-upgrade-migration description: >- Migrate an existing Salesloft integration through an evidence-backed endpoint, auth, schema, scope, and behavior diff with shadow validation and rollback. Use when current contracts or application assumptions change. Trigger with "Salesloft migration", "upgrade Salesloft integration", or "Salesloft API contract change". argument-hint: "[repository-path] [migration-scope]" allowed-tools: Read, Glob, Grep, WebFetch, Write, Edit version: 1.6.0 author: Jeremy Longshore jeremy@intentsolutions.io license: MIT tags:

• saas
• salesloft
• migration model: inherit effort: medium compatibility: Designed for Claude Code

---

Salesloft Contract Migration

Overview

This skill migrates the integration that actually exists. It does not assume a generic v1-to-v2 journey, API-key deprecation, or universal endpoint rename.

Prerequisites

• Current integration commit, dependencies, deployment topology, and owners
• Complete method/path/scope/request/response inventory
• Target official documentation and migration reason
• Sanitized fixtures, shadow environment, rollback, and reconciliation plan

Tool Discipline

Use Read, Glob, and Grep to inventory callers, auth, schemas, and compatibility code. Use WebFetch only for current official Salesloft documentation. Use Write or Edit after the migration boundary is approved.

Current Contract

• The current public reference exposes v2 and historical v1 surfaces; compatibility is endpoint-specific.
• Resource paths are documented without a universal .json requirement.
• Auth flow choice depends on integration type; API keys remain a customer path and client credentials remain private-use only.
• Rate costs and endpoint schemas can change independently of URL versioning.
• Cadence import, export, and membership contracts must be verified from their own endpoint pages.

Authentication

Treat auth migration as a separate reversible workstream. Preserve tenant binding and least privilege, and do not disable the old credential until the new path is proven and rollback is viable.

Instructions

1. Inventory every live method, path, query, content type, scope, response field, and retry assumption.
2. Diff each used contract against current official documentation and classify required changes.
3. Add failing fixtures for every intentional schema or behavior delta.
4. Implement an adapter or dual-read path instead of changing all callers at once.
5. Shadow reads and compare normalized results without duplicating writes.
6. Canary approved mutations with read-after-write and reconciliation evidence.
7. Cut over gradually, monitor rate and error signals, then remove compatibility code only after rollback expiry.

Approval Boundaries

Do not automatically fall back between API versions, convert auth flows, import cadences, or replay writes. Each live mutation and irreversible cleanup needs explicit approval.

Output

Return contract diff, affected callers, fixture results, shadow comparison, canary evidence, cutover state, rollback trigger, and cleanup date.

Error Handling

Condition	Response
Undocumented behavior	Stop and obtain provider or support confirmation.
Shadow mismatch	Keep old reads authoritative and isolate the field delta.
Canary uncertainty	Reconcile before retry or wider rollout.
Rate regression	Halt expansion and compare endpoint/page cost.

Examples

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

contracts=14; changed=3; shadow-match=100%; canary=pending; rollback=ready

Resources

• Skill-specific official documentation
• Salesloft API reference
• Request and response format