outreach API 422 error on prospect create - mailbox already exists as a prospect

TL;DR

The mailbox is already a prospect in Outreach, so create is the wrong call. Look the prospect up by email first and update the existing record (mailbox settings, sequence assignment) instead of creating a duplicate.

outreach API 422 error on prospect create  -  mailbox already exists as a prospect

Steps

1. Read the 422 response body for the existing prospect's id or the conflicting field. Expected: you can identify the existing prospect record.

2. Look up the prospect by email through the Outreach prospects endpoint to get its current state. Expected: the existing prospect with its mailbox and sequence assignments.

3. Apply the intended changes (mailbox association, tags, sequence enrollment) as an update to the existing prospect, not a create. Expected: the update returns 200 and the prospect reflects the new state.

4. Change the agent's flow to lookup-before-create: check for the prospect by email, update on hit, create on miss. Expected: no more 422s on re-runs of the same list.

5. If the same list gets processed twice, make the second pass a pure update pass by reusing the ids from the first pass. Expected: re-uploads and retries are idempotent.

Use this when

• Prospect create returns 422 and the address already exists in Outreach.
• A CSV re-upload or a retried run re-creates the same prospects.
• The agent has no upsert logic on the prospect path.

Not for this skill when

• The 422 is a validation error on a genuinely new prospect.
• The failure is a 401, 403, or 429.
• The mailbox itself fails to connect (a mailbox-settings problem, not a prospect problem).

Variant phrasings

• "outreach prospect create 422 already exists"
• "mailbox already a prospect outreach api"
• "outreach duplicate prospect 422 on create"

Why it happens

Outreach treats the prospect's email as unique. Agents that create-then-handle-errors, or that reprocess a list without remembering the first pass, collide with their own earlier creates. The 422 is the dedupe working; the agent's flow just never learned the update path.

Edge cases

• The existing prospect may be owned by another user or locked. Surface that to the operator instead of force-updating.
• Email case differences ([recipient email] vs [recipient email]) can dodge the lookup. Normalize case on the lookup key.
• If the prospect exists but under a different mailbox, decide the merge rule before updating.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstIFzh253atdMVdq2w-IwcQ