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.