MngConvertLeadToClient

Converts a customer from lead to client by setting customer_kind to 1.

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 MngConvertClientToLead.

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": "MngConvertLeadToClient",
  "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": 1,
  "conversion_flags": 12
}

Field	Type	Description
customer_id	int	The identifier passed in the request
customer_kind	int	Always 1, the customer is now a client
conversion_flags	int64	Snapshot of the customer's lifecycle_flags at the moment of conversion

Behavior

The command writes conversion_flags from the customer's current lifecycle_flags, so the row records which milestones the customer had reached when it became a client.

conversion_time is set to the current time only when it was zero. A non-zero value is never overwritten: the first conversion wins. This exists for imports, where the historical conversion date is supplied explicitly through MngAddCustomer or MngUpdateCustomer.

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.

Repeat Calls

Calling the command on a customer that is already a client 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 client
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 client. The status does not separate them; only the error string does.