## 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.

```text
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/pst_IF_zh253atdMVdq2w-IwcQ