When to use this endpoint

Use CustomerType_delete only after moving every active customer away from the classification. Both CRM customer-type screens use this endpoint.

Authentication and permissions

The request must authenticate with signed API-key fields or a logged-in CRM session. The handler performs no additional page or role-permission check.

The lookup and any write use the authenticated tenant; an ID from another tenant cannot be addressed through this call.

Parameters

ParameterTypeRequiredDescription
idInteger stringYesPositive customer-type ID.

Example request

$result = FM_api('CustomerType_delete', [
	'id' => '12',
]);

Example response

{
  "ok": 1
}

Errors and unusual responses

ResponseCondition
{"error":"not logged in"}No authenticated tenant context is available. Invalid signed credentials can be rejected by the dispatcher before the handler runs.
{"error":"missing or invalid parameter: id"}The ID is absent, zero, negative, or nonnumeric.
{"error":"customer type does not exist"}No row exists for the tenant and ID.
{"error":"cannot delete customer type because it is used by at least one customer"}At least one non-deleted customer currently has this type.

Legacy application errors may be returned with HTTP 200. Check the decoded response for error, not only the HTTP status.

Behaviour and edge cases

  • Only customers with deleted=0 block deletion. Soft-deleted customers can retain an ID that no longer resolves to a customer-type row.
  • The endpoint does not check whether another type’s allowed_next list refers to this ID.

Side effects

  • Hard-deletes the type and records the ID in the tenant deletion log.
  • It does not edit customer records, allowed-next lists, or trigger configurations.

See it in Fieldmotion

CRM1

Open Settings → Customer Types, choose a type’s delete action, and confirm it.

CRM2

Open Settings → Customer Types, select a row, and choose the delete action. CRM2’s permission UI is client-side; the handler itself has no role check.

Related endpoints