MngConvertClientToLead

Returns a customer from client back to lead by setting customer_kind to 0.

The command is available through the manager command API only; there is no REST path for it. The direction is fixed by the command name, so the request carries no customer_kind field. The opposite direction is MngConvertLeadToClient.

See Lead and Client Kind for the fields these two commands maintain.

Access Control

Allowed sessions:

• SESSION_MANAGER
• SESSION_ADMIN
• SESSION_DEALER
• SESSION_CRM_MANAGER
• SESSION_CRM_ADMIN

The caller must have CRM access and set_customers. Beyond the permission, the target customer is checked against the caller's brand and desk scope. A customer outside that scope is refused with 403, not reported as missing.

Every call is written to the journal, successful ones included.

Request

{
  "command": "MngConvertClientToLead",
  "extID": "1",
  "data": {
    "customer_id": 500
  }
}

Request Data

Field	Type	Required	Description
customer_id	int	Yes	Target customer id, 1 or greater

No other fields are accepted. customer_kind in particular is not an input; the command name is the direction.

Response Data

{
  "customer_id": 500,
  "customer_kind": 0,
  "conversion_flags": 0
}

Field	Type	Description
customer_id	int	The identifier passed in the request
customer_kind	int	Always 0, the customer is a lead again
conversion_flags	int64	Always 0, the conversion snapshot is cleared

Behavior

The command clears both conversion fields: conversion_flags and conversion_time are set to 0, which restores the lead invariant described in Lead and Client Kind. updated_time is refreshed.

Two events are published: the internal customer.push record with code EV_RECORD_UPDATE, and the internal customer.updated record carrying the previous status, milestone flag mask, and kind. Modules receive the latter as customer.update; the customer.push record is not exported by that mapping.

Because conversion_time is cleared here and MngConvertLeadToClient only writes it when it is zero, converting a customer back and then forward again records a new conversion date rather than the original one.

Repeat Calls

Calling the command on a customer that is already a lead returns 400 with RET_INVALID_DATA and changes nothing.

This differs from the removed MngSetCustomerKind, which returned 200 and silently did nothing in the same situation. Integrations that relied on that behavior must handle the error.

The workflow action of the same name is deliberately asymmetric: it skips such a customer quietly, because a workflow rule fires repeatedly by nature.

Errors

HTTP	Error	Description
400	INVALID_DATA	customer_id is missing, is not a number, or is less than 1
400	RET_INVALID_DATA	The customer is already a lead
403	RET_NOT_ENOUGH_RIGHTS	Missing permission, missing scope, or the customer is outside the caller's visibility
404	RET_NOT_FOUND	No customer with that identifier exists

Every error carries a message field with free-form human-readable text. Its contents are not part of the contract; branch on error.

INVALID_DATA and RET_INVALID_DATA Are Different

Both arrive with status 400 and mean different things. INVALID_DATA is a malformed request: fix the payload. RET_INVALID_DATA is a refusal based on the customer's current state: the request was well formed, but the customer is already a lead. The status does not separate them; only the error string does.