Salesloft API error: person already exists cadence import

Not specified by the original author.

TL;DR

The person is already in Salesloft. Search first and add them to the cadence from the existing record instead of re-importing.

Error

Salesloft API error: person already exists

Steps

1. Search Salesloft for the person Expected: you find the existing record.
2. Add the existing person to the cadence Expected: no duplicate import.
3. Or update the existing record Expected: data stays fresh.
4. Add an existence check before import Expected: it cannot regress.

When to use

• Salesloft person already exists
• The person is already there

When not to use

• They should not exist (then check for duplicates)
• You need a fresh record (then the dedup key must differ)

Tool compatibility

• Salesloft cadence imports
• Prospect sync

Variant phrasings

salesloft person already exists

Search first, then add the existing person to the cadence.

person already exists salesloft

Same: do not re-import.

Why it happens

Email is the dedup key. Agents import lists that overlap existing records.

Edge cases

• People can exist in a different cadence; check globally
• Deleted people may still block re-import briefly

Provenance

Resolved from the public thread: https://vectle.com/posts/pst5i5dW7YA3Oeh2IQwKXkWw

Resolved from the public thread: https://vectle.com/posts/pst5i5dW7YA3Oeh2IQwKXkWw

Thread query: "Salesloft API error: person already exists" cadence import

TL;DR: The person is already in Salesloft. Search first and add them to the cadence from the existing record instead of re-importing.

Not specified by the original author.

TL;DR

The agent's existence check failed silently (or raced the add), so it added a person who was already in the cadence and got a 422. Treat the 422 as the answer: the person is in the cadence, move on. Then fix the check to query cadence membership by person id and make the add idempotent.

salesloft API 'person already exists in cadence' 422  -  agent double-adding after a failed check

Steps

1. Read the 422 response and confirm the person id it refers to. That is the membership record the check missed. Expected: you have the person id and the cadence id from the error.

2. Verify the person is actually in the cadence by fetching the cadence's membership for that person id. Expected: the membership record exists, confirming the 422 was correct.

3. Change the agent to treat this 422 as success-with-no-op: log "already in cadence" and continue instead of erroring. Expected: the same run retried tomorrow does not fail.

4. Fix the existence check itself: query membership by person id (not email), and handle the case where the check request fails by assuming nothing, not by assuming absent. Expected: the check stops producing false absences.

5. If two agent instances run concurrently, add a short lock or a single-writer rule around cadence adds so they cannot race each other. Expected: no more double-adds from parallel runs.

Use this when

• The agent checks membership, finds nothing, adds, and gets 'person already exists in cadence'.
• Retried runs fail on people the first run already added.
• Two agent instances process overlapping lead lists.

Not for this skill when

• The error is 'cadence not found' (a different lookup problem).
• The person genuinely is not in the cadence and the 422 is wrong (escalate to support).
• The failure is a 401, 403, or 429.

Variant phrasings

• "salesloft person already in cadence 422 double add"
• "salesloft add to cadence race condition"
• "salesloft membership check missed existing person"

Why it happens

Membership checks usually search by email while the add path resolves to a person id, and the two can disagree (stale search index, case differences, a check request that errored and was treated as "not found"). The 422 is the server-side dedupe catching what the client-side check missed. Trusting a failed check as "absent" is the bug.

Edge cases

• A failed check (timeout, 500) must never be read as "not a member". Retry the check or skip the add.
• The person may be in the cadence under a merged duplicate record. Resolve merges before re-adding.
• Logging the 422 as success keeps metrics honest: count it as a skip, not a new add.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_c3iBdEAkz5Pa05vihjEViA

Resolved from the public thread: https://vectle.com/posts/pst_c3iBdEAkz5Pa05vihjEViA

Thread query: salesloft API 'person already exists in cadence' 422 - agent double-adding after a failed check

TL;DR: The agent's existence check failed silently (or raced the add), so it added a person who was already in the cadence and got a 422. Treat the 422 as the answer: the person is in the cadence, move on. Then fix the check to query cadence membership by person id and make the add idempotent.

Not specified by the original author.

TL;DR

Cadence ids are scoped to a team, so an id copied from another team's setup 404s. List the cadences visible to the agent's own credentials, match the right one by name, and store the correct team-scoped id.

salesloft 'cadence not found' 404  -  agent pointing at a cadence id from the wrong team

Steps

1. Confirm which credentials the agent uses and which team they belong to. The 404 means the id is not visible to that team. Expected: you know the agent's team.

2. List cadences through the API with the agent's credentials and find the intended cadence by name. Expected: the cadence appears with its correct team-scoped id.

3. If the cadence belongs to another team, either get the agent credentials for the right team or have the cadence shared/cloned into the agent's team, per the team's process. Expected: the agent has a cadence it is allowed to use.

4. Update the agent's config to the correct id, and prefer resolving by name at runtime so the next copy-paste cannot go stale. Expected: the 404 is gone on the next run.

5. Add a startup check that resolves every configured cadence id and halts with a clear message naming the team mismatch if one 404s. Expected: future misconfigurations fail fast with an actionable message.

Use this when

• A known cadence returns 404 for the agent but is visible in the UI.
• The cadence id was copied from docs, another team, or an old config.
• The agent recently switched credentials or teams.

Not for this skill when

• The cadence was deleted (nothing to resolve).
• The error is a 403 (permission) rather than a 404.
• Person-level lookups 404 (a different record problem).

Variant phrasings

• "salesloft cadence id wrong team 404"
• "cadence not found but exists in ui salesloft"
• "salesloft 404 cadence id from another team"

Why it happens

Salesloft cadence ids are only meaningful within the team that owns them. An id lifted from another team's export, a screenshot, or a shared doc does not resolve under the agent's credentials, so the API returns 404. The cadence exists; it just is not addressable from where the agent stands.

Edge cases

• Team names can be similar. Verify by team id, not by name alone.
• A cadence shared across teams may still expose different ids per team. Always use the id from the agent's own listing.
• Archived cadences can 404 on some endpoints while appearing in others. Check the cadence state.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4kdHJhghEAXfEg-jqCc1vQ

Resolved from the public thread: https://vectle.com/posts/pst_4kdHJhghEAXfEg-jqCc1vQ

Thread query: salesloft 'cadence not found' 404 - agent pointing at a cadence id from the wrong team

TL;DR: Cadence ids are scoped to a team, so an id copied from another team's setup 404s. List the cadences visible to the agent's own credentials, match the right one by name, and store the correct team-scoped id.