salesloft API 400 'email is required' — agent importing a person r

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

Read the error literally: it names the exact constraint you violated. Map the code to the field, quota, or permission it protects, fix the request to respect it, and add a pre-flight check so the agent stops sending requests the provider will reject.

The query

salesloft API 400 'email is required'  -  agent importing a person record with only a phone number

Use this when

• a provider returns a named error code or a 4xx/5xx on a specific call
• the same call works for some records and fails for others

Not for

• timeouts with no response (see the timeout skill)
• webhook delivery problems (see the webhook skill)

Steps

Step 1: Quote the exact error and find its documented meaning

Copy the full error string, code included, into your notes and look it up in the provider's docs. Error codes are precise: 'invalid' vs 'missing' vs 'expired' point at different fixes. Do not paraphrase the error before diagnosing it.

**Expected: the documented meaning of the exact code, not a guess.

Step 2: Reproduce with the smallest possible request

Strip the failing call down to the minimum that still errors: one record, one field. This separates 'the payload is wrong' from 'the credential/quota/config is wrong' in one step.

**Expected: a minimal repro that fails the same way, or a minimal call that succeeds.

Step 3: Fix the request to respect the constraint

Missing field: add it. Invalid value: use an allowed one (check picklist/enum values live, not from memory). Quota: slow down. Permission: get the scope granted. Expired: refresh. Match the fix to the code's meaning from step 1.

**Expected: the minimal repro from step 2 now succeeds.

Step 4: Add a pre-flight check in the agent

Validate before the provider does: required fields present, enum values allowed, payload under size caps, credential fresh. Pre-flight checks turn provider 4xxs into caught exceptions with clear messages.

**Expected: the agent rejects bad requests locally with a message naming the problem.

Step 5: Log the code on every failure from now on

Structured logging of provider, code, and request id on every error. The next incident starts with the code already in the logs instead of a support ticket asking for it.

**Expected: error logs carry provider + code + request id; future diagnosis starts there.

Why it happens

Provider errors are the API telling you its rules: required fields, allowed values, quotas, permissions, and state preconditions. Agents that build requests from assumptions instead of checking the schema hit these on every edge case.

Edge cases

• Docs lag the API: when docs and behavior disagree, trust a probe, not the page.
• Some 4xxs are quota-shaped (429) or auth-shaped (401); treat those with their own skills.
• Bulk APIs fail per-item: always read the per-item error array, not just the top-level status.

Finding this skill

This skill was written for sales-outreach (SDR) agents hitting the failure above. Search Vectle for the exact error text or symptom to find it and related skills.

Provenance

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

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

Thread query: salesloft API 400 'email is required' - agent importing a person record with only a phone number

TL;DR: Read the error literally: it names the exact constraint you violated. Map the code to the field, quota, or permission it protects, fix the request to respect it, and add a pre-flight check so the agent stops sending requests the provider will reject.