Update one mapped customer field

When to use this endpoint

Use Customer_updateField only for established callers that already use a Customer field-map key plus val.

Prefer Customer_updateData for new work: this wrapper bypasses several customer-specific validations and has duplicate history behavior.

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	Non-deleted customer ID. The wrapper is designed for one ID.
`field`	String	Yes in practice	Customer map key to update, such as `name`, `accountNumber`, `streetAddress1`, `parentId`, `isActive`, `type`, or an allow-listed metadata key. An unknown/blank key yields a warning rather than a field-specific error.
`val`	Mapped scalar/JSON value	Yes in practice	New field value. If it is the empty string, the wrapper does not copy it into the named field, so `field` plus blank `val` normally cannot clear a value.
`do_not_run_trigger`	Integer/boolean-like	No	Consulted only when `field=type`. Truthy suppresses configured customer-type email triggers.
`<other mapped keys>`	Mapped values	No	Because the entire request is passed to the generic updater, additional recognized map keys can also be updated in the same call. Do not rely on this accidental multi-field behavior.

Example request

$result = FM_api('Customer_updateField', [
	'id' => '1042',
	'field' => 'name',
	'val' => 'Northwind Service Centre',
]);

Example response

{
  "ok": 1,
  "oldData": {
    "name": "Northwind Services"
  }
}

oldData includes prior mapped values selected for this update. Some duplicate map aliases resolve to the first field-map key for the underlying column.

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":"missing or invalid parameter: id"}`	`id` is absent.
`{"error":"missing or invalid parameter: name"}`	For example, `field=name` supplies an empty value to a map-required field through another request key.
`{"warning":"no updated fields."}`	No recognized mapped field has a supplied value, including the normal blank-`val` or unknown-field cases.
`{"warning":"No data.","oldData":[]}`	The ID is unknown or soft-deleted.
`{"warning":"No Change."}`	Recognized values convert to their already-stored values.
`null`	A nonzero `type` was already stored, then its referenced customer type or customer lookup failed in the post-update trigger path.

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

Behaviour and edge cases

Customer-specific validation is bypassed. This route does not run the length, country, due-date, duplicate-name, or contact-number checks in Customer_updateData. It also accepts hidden field-map keys. Do not expose arbitrary field/val input to users.

The generic update excludes soft-deleted rows and converts the selected value according to the customer field map.
A successful change updates last_edited. The wrapper does not set an edited_uuid value.
isActive=0 runs recurrence deactivation after the row update. Other lifecycle fields and references receive no special validation.
For type, the row is updated before the type record is validated. An invalid type can therefore remain stored even though the endpoint returns JSON null afterward.
There is no pagination.

Side effects

The generic helper writes activity logs and a customer change-history row. Customer_Log then writes another customer change-history row for the same ordinary field, so duplicate history entries are a known legacy quirk.
A type update can add a further explicit type-history row and queue configured type-trigger emails. Their legacy queued body is the placeholder text Test with template data in metadata.
Address/name/parent changes synchronize address history; deactivation stops recurrences and removes their future incomplete jobs.
The route does not send mapped update notifications or fire the general Customer_edit event.

See it in Fieldmotion

CRM1

No current production CRM1 caller was found. The endpoint is retained for legacy/generic field editing and is covered by API regression tests.

CRM2

No direct production CRM2 caller was found; configurable layouts use Customer_updateData.

Related endpoints

Customer_updateData performs the supported mapped update workflow.
Customer_setType validates customer types before applying type-specific triggers.
Customer_getChangesDT exposes the resulting history rows.