Fieldmotion API Getting started

Customers

Migrate one legacy customer history

POST /a/Customer_optimiseChanges

Migrate one customer’s embedded legacy change-history array into the customer change-history table.

When to use this endpoint

Customer_optimiseChanges is a compatibility maintenance route used during login/footer processing. New integrations should not call it.

It operates on the obsolete customers.changes blob and does not optimize current rows already stored in customer_changes.

Authentication and permissions

The request must establish tenant context. The handler checks for DBP but performs no page or role-permission check.

Parameters

ParameterTypeRequiredDescription
idInteger stringYesCustomer whose embedded legacy changes are migrated.

Example request

FM_api('Customer_optimiseChanges', [
	'id' => '1042',
]);

Example response

null

The function has no explicit success return. Depending on the transport wrapper, callers can observe JSON null or an empty body.

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"}id is absent or not positive.

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

Behaviour and edge cases

  • A missing customer behaves like an empty history: the update is attempted and the endpoint returns no success object.
  • Each legacy HTML table fragment is parsed into a label plus old/new strings. Labels are truncated to 128 bytes.
  • An exact existing row with the same customer, timestamp, user, label, and encoded values is skipped.
  • If at least one row is inserted, last_edited is updated. Soft-deleted customers are not excluded.
  • There is no pagination.

Side effects

  • Replaces customers.changes with [], inserts zero or more customer_changes rows, and may update last_edited.
  • Does not emit customer notifications or the Customer_edit event.

See it in Fieldmotion

CRM1

CRM1 invokes one migration internally near the end of page rendering when it finds a customer with a nonempty legacy changes blob; it is not normally visible as a browser API request.

CRM2

The shared login-loading path can invoke the migration internally. No direct CRM2 JavaScript caller was found.

Related endpoints