---
title: "Rename Deal"
method: POST
path: "/api/prospecting/deals/{deal_id}/rename"
tags: ["prospecting"]
---

# Rename Deal

`POST /api/prospecting/deals/{deal_id}/rename`

Rename the display fields of one deal.

Mirrors the chat agent's `rename_pipeline_deal` tool so both surfaces write
the same two columns and nothing else.

## Query parameters

- `user_id` string, nullable
- `org_id` string, nullable

## Request body

- RenameDealRequest — Display-only rename. Deliberately carries NO contact/client field. Two wire shapes, branched on payload (2026-09-02 rename-contract fix — the naming-rearchitecture web client's single-field inline editor used to send the whole edited title as `target_name` alone; the legacy two-field composer below then recombined it with the deal's EXISTING `target_company_name`, double-appending the company on every contact-led rename — reproduced on staging as "Mo Malayeri - Bettermode - Bettermode", 2026-09-01 E2E): - `name` present → the new single-field contract. The value IS the complete desired deal name already; written verbatim to `name` (+ `name_source='user'` + audit cols + a `deal.renamed` event). For a LEAD the same value goes to `target_name` instead (the prospect label — leads carry no `name` column). The transitional deal-side dual-write to `target_name` was retired 2026-09-01 with the split finale; `target_company_name` is never touched or recomposed. - `target_name` / `target_company_name` present, `name` absent → the legacy two-field contract (current prod web pre-rearchitecture, MCP, the chat agent's `rename_pipeline_deal` tool): unchanged composition into `name` as `"Contact - Company"` (never a duplicated "X - X"). `target_name` / `target_company_name` are a display snapshot on the deal row, not a join to the linked contact — so this changes the board label and nothing else. Re-pointing a deal at a different person is NOT exposed here: `dedupe_key` is `manual:<contact_id>` and the suppression/identity checks run against that contact at creation, so swapping it without recomputing both could mint a second live deal for one human. That repair is archive + re-add, which recomputes everything.
  - `name` string, nullable
  - `target_name` string, nullable
  - `target_company_name` string, nullable

## Response `200`

Successful Response

- unknown

## Other responses

- `422` — Validation Error

## Changes

- **2026-09-01** `597eaca86c48` — 1 info
  - added the new optional request property `name`
- **2026-08-19** `1c7d3d9ad035` — 1 info
  - endpoint added

[Change history](https://skmtc.dev/every/apis/every-api/changes/api/prospecting/deals/:deal_id/rename/post.md)

---

[API](https://skmtc.dev/every/apis/every-api.md) · [All operations](https://skmtc.dev/every/apis/every-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/every/every-api/revisions/cd6453ae5786/schema)