Fieldmotion API Getting started

Tasks

Set a task customer

POST /a/Task_setCustomerId

Replace a task’s customer ID through the focused CRM1 editor contract.

When to use this endpoint

Use Task_setCustomerId when changing the customer from a legacy task editor. It cannot clear the customer; mapped updates can store zero if that legacy state is required.

Authentication and permissions

The request must establish an authenticated tenant context with signed API credentials or a logged-in CRM session. The handler checks for the tenant database prefix rather than calling the normal login guard.

It performs no additional task, page, role, ownership, or privacy-permission check. A caller that knows an active task ID in its tenant can address it regardless of the CRM screens’ visibility rules.

Parameters

ParameterTypeRequiredDescription
idInteger-compatibleYesTask ID greater than zero. Row existence is not checked.
customer_idInteger-compatibleYesNonzero customer ID. The customer is not looked up, so an unknown positive ID is accepted.

Example request

$changed = FM_api('Task_setCustomerId', [
	'id' => '318',
	'customer_id' => '1088',
]);

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":"no id parameter"}ID is absent or integer-coerces to zero.
{"error":"no customer_id parameter"}Customer ID is absent or integer-coerces to zero.

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

Behaviour and edge cases

  • Updates client_id and last_edited without checking whether either the task or customer exists.
  • There is no active-row condition, so a deleted task can be modified. A nonexistent task still produces success because affected-row count is ignored.
  • Existing task/job links are not revalidated when the customer changes.

Side effects

  • Invalidates the task cache. No field-history, notification, or email side effect runs.

See it in Fieldmotion

CRM1

Open Tasks, edit a task, and change the corresponding field. CRM1’s task dialog and Task Main page load Task_get and save changed fields through the focused Task_set* routes.

CRM2

No direct production CRM2 caller was found. CRM2 task layouts save customer changes through Task_updateData.

Related endpoints

  • Task_updateData accepts mapped customer/customerID and records field history.
  • Task_get returns the new ID as customer_id.