---
title: "Resolve Copilot Contact Contribution"
method: POST
path: "/copilot/personal-wiki/contact-sharing/contributions/{contribution_id}/resolve"
tags: ["Copilot"]
---

# Resolve Copilot Contact Contribution

`POST /copilot/personal-wiki/contact-sharing/contributions/{contribution_id}/resolve`

## Request

- Base URL: `https://be.graph8.com/api/v1`
- URL: `https://be.graph8.com/api/v1/copilot/personal-wiki/contact-sharing/contributions/{contribution_id}/resolve`
- Auth: HTTP bearer

Decide ONE FIELD of a contribution: keep the CRM value, or take the
proposed one.

Per field rather than per contribution, because a contribution can be right
about a job title and wrong about a surname.

TWO concurrency tokens are required and both are load-bearing: one for the
contribution and one for the CANONICAL contact record the decision would
change. Either having moved means the decision was made against something
that no longer holds, and `use_proposed` OVERWRITES a shared record.

## Path parameters

- `contribution_id` string, required: Contribution id (UUID).

## Headers

- `Authorization` string, nullable
- `X-Target-Org-Id` string, nullable

## Request body

- PersonalContactReviewRequest: Mirror of `PersonalContactReviewRequest`.
  - `expected_revision` integer, required: The contribution's revision.
  - `expected_canonical_revision` string, required: Digest of the CANONICAL contact record as you read it. Two tokens are required because two records are in play: the contribution and the contact it would change. Either moving means the decision was made against something that no longer holds.
  - `field` 'CONTACT_FIRST_NAME' | 'CONTACT_LAST_NAME' | 'CONTACT_JOB_TITLE', required: Which field is being decided.
  - `choice` 'keep_current' | 'use_proposed', required: `keep_current` - the CRM record wins. `use_proposed` - the contributed value wins and overwrites it.

## Response `200`

Successful Response

- ApiResponseCopilotMemoryPayload
  - `data` CopilotMemoryPayload, required: An open envelope for one memory, wiki or sharing answer. Open because the personal wiki is a DOCUMENT whose sections follow what has been learned about a person, and because each fact carries provenance - which mailbox or meeting it came from - that grows as new sources are connected. Pinning the shape would silently drop the provenance on the newest source, and on a "what do you know about me" surface a fact with no visible origin is worse than no fact.
  - `pagination` PaginationMeta
    - `page` integer, required: Current page number (1-indexed)
    - `limit` integer, required: Items per page
    - `total` integer, required: Total number of items
    - `has_next` boolean, required: Whether there are more pages
    - `next_cursor` string, nullable: Opaque cursor for the next page; null when there are no more items. Pass it back as the `cursor` query param to fetch the following page without computing page numbers.
    - `total_available` integer, nullable: Search endpoints only: how many records really match, when known. Can be larger than `total`, which is capped at the 10,000 results that can be paged. For company search this is a distinct-company estimate. Null when unknown; absent outside search.
    - `total_is_lower_bound` boolean, nullable: Search endpoints only: true when more records match than `total` shows (the result set is larger than the 10,000 results that can be paged). Absent outside search.
    - `notes` string[], nullable: Search endpoints only: plain-language notes about the result, e.g. that more records match than can be paged, or that a reversed `between` range was put in order.

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/graph8/apis/graph8-developer-api.md) · [All operations](https://skmtc.dev/graph8/apis/graph8-developer-api/llms.txt) · [OpenAPI document](https://skmtc.dev/graph8/apis/graph8-developer-api/revisions/89fc11143b70?raw)