Leads - Admin

Create a lead from the backoffice

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.

post/api/leads

Headers

x-api-tokenstring nullable

Response

Successful Response

{"stackTrail":"paths:/api/leads:post:responses:200:content:application/json:schema","oasType":"schema","type":"unknown"}

Changes

No recorded changes to this endpoint across all 1 revision of this API.