Set a customer type · Fieldmotion API

When to use this endpoint

Use Customer_setType when changing one existing customer’s tenant-defined type and the caller intentionally wants the configured type-change behavior.

Load a valid customer-type ID first. Clearing the type uses zero, but omitting type also silently converts to zero.

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

Parameter	Type	Required	Description
`id`	Integer string	Yes	Customer ID. Only presence is validated before integer conversion and lookup.
`type`	Integer-like value	Effectively yes	Existing tenant customer-type ID, or `0` to clear. The handler does not check presence: omission and blank input both convert to zero and may clear the current type.
`do_not_run_trigger`	Integer-like value	No	Internal bypass. A nonzero value suppresses the selected type’s email triggers. External integrations should not use this to bypass configured business automation without explicit agreement.

Example request

$result = FM_api('Customer_setType', [
	'id' => '1088',
	'type' => '4',
]);

Example response

{
  "ok": 1,
  "triggers": [
    {
      "target": "customer",
      "template": "21",
      "subject": "Welcome",
      "replyto": "support@example.com"
    }
  ]
}

triggers echoes the selected type’s decoded trigger configuration when triggers run. It is [] when clearing or suppressing triggers, and can be null when a type stores JSON null.

An unchanged type returns {"ok":1,"msg":"type already set to new value"} and does not include triggers.

Errors and unusual responses

Response	Condition
`{"error":"not logged in"}`	No authenticated tenant context is available. Invalid signed credentials can be rejected by the dispatcher before the handler runs.
`{"error":"no ID supplied"}`	`id` is omitted.
`{"error":"customer does not exist"}`	No customer row matches the converted ID.
`{"error":"that customer type does not exist"}`	A nonzero converted type is not present in the tenant’s customer-type table.

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

Behaviour and edge cases

The customer and customer-type lookups do not filter active or deleted rows.
Zero clears the type without a reference lookup. An omitted type has the same effect, which is a legacy quirk.
The endpoint does not validate department compatibility even if the CRM interface limits departments by customer type.
Only triggers whose target is customer, and only customers with a truthy email value, produce queued mail.
This is a single-record mutation; it provides no list filtering or pagination.

Side effects

The customer write updates type, last_edited, and edited_uuid. A per-field timestamp/user entry is also stored in last_edited_all. The handler does not explicitly invalidate the customer cache or fire Customer_edit.
A customer_changes row labelled type records the old and new values, and a customer audit event is written.
Eligible type triggers queue type-2 mail for the customer using the configured template, subject, and reply-to values. The response reports configuration, not mail-delivery completion.

See it in Fieldmotion

CRM1

The legacy Customers table and customer edit popup call Customer_setType; internal customer create/edit flows also use it when applying type changes.

CRM2

CRM2 presents customer type through its broader layout editor. No direct production CRM2 call to this focused endpoint was found.

Related endpoints

Customer_setDepartmentId changes the separate department assignment.
Customer_get retrieves the stored type and related customer fields.