---
title: "Create a lead from the backoffice"
method: POST
path: "/api/leads"
tags: ["Leads - Admin"]
---

# Create a lead from the backoffice

`POST /api/leads`

Create a lead by hand from the backoffice ("Criar Lead" dialog).

Why this exists instead of reusing POST /public/leads, which the dialog used
to call:

* **Identity.** The public route depends on `get_current_user_optional`,
  which does NOT apply the `x-admin-company` / Z_UserCompanyAccess override
  (that lives in `get_current_user`). So while impersonating, the vehicle
  picker listed company X's cars and the lead was filed under the
  operator's HOME company. On the protected router the two agree.
* **`object_id` id space.** The picker sends a `Viatura.ID`; a website form
  sends a `ViaturasEasyDataGreen.ID`. The ranges overlap, so the historical
  "convert every object_id through the listing table" step silently
  re-pointed a hand-picked car at an unrelated one (measured: 656 of
  company 1's vehicles would land on a different car of the same company,
  204 on another tenant's). Here the field is named `vehicle_id` and the id
  space is declared, not guessed.
* **Mass assignment.** The public route merges unknown raw-form keys into
  the payload before it knows who the caller is. This route takes declared
  params only.

POST /public/leads keeps working unchanged for website forms AND for cached
frontend bundles still posting there.

## Headers

- `x-api-token` string, nullable

## Response `200`

Successful Response

- unknown

## Other responses

- `422` — Validation Error

---

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