# unassignContact

Take teammates OFF contacts: the removal twin of assignContact, and the offboarding op. userIds is a LIST, so one call clears several teammates from the selection; each is removed from every selected contact whatever their role (POINT_PERSON or PARTICIPANT), so this does not demote anyone (re-assign with assignContact(role: PARTICIPANT) for that). A user not on a contact is skipped, not failed. Async bulk job: returns a bulkTaskId to poll with getBulkTask; an immediate read-back will not show the change. It hands the work to nobody, with ONE exception you must not report as a general rule: if EXACTLY ONE assignee is left and they are a PARTICIPANT, they are promoted to POINT_PERSON on that contact. Any other shape (nobody left, or two or more) leaves no point person, so the contact drops out of the removed teammate’s queue without entering anyone else’s. Because the outcome differs per contact, do not say who owns what until you have re-read the contacts (getContact `participants`); for a deliberate hand-off, follow with assignContact for the new owner rather than rely on the promotion.

- Call: `POST https://server.goliathdata.com/api/v1/call` with `{ "operationId": "unassignContact", "variables": {...} }`
- Scope: `WRITE`
- Type: mutation
- Idempotency: honors `Idempotency-Key` (24 h)
- Rate-limited: no

## Variables

- `contactIds`: `[String!]!` (required)
- `userIds`: `[ID!]!` (required)

## Response (data, an example)

```json
{
  "contactMutation": {
    "bulkUnassignUsersFromContacts": {
      "mode": "SYNC",
      "bulkTaskId": "…"
    }
  }
}
```

## Example

```bash
curl https://server.goliathdata.com/api/v1/call \
  -H "Authorization: Bearer $GOLIATH_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "operationId": "unassignContact",
    "variables": {
      "contactIds": [
        "<String>"
      ],
      "userIds": [
        "<userIds>"
      ]
    }
  }'
```