When to use this endpoint

Use Task_setType for CRM1’s task type selector. It stores an integer ID but does not verify that a matching type exists.

Authentication and permissions

The request must authenticate with signed API-key fields or a logged-in CRM session. The handler calls the normal login guard but performs no additional task, page, role, ownership, or privacy-permission check.

All reads and writes use the authenticated tenant. CRM1 and CRM2 apply task visibility and editing permissions in their interfaces, but these handlers do not repeat those client-side rules.

Parameters

ParameterTypeRequiredDescription
idInteger-compatibleYesTask ID. Row existence and active state are not checked.
typeInteger-compatibleNo in implementationTask type ID. Missing or nonnumeric input becomes 0; unknown/negative IDs are accepted.

Example request

$changed = FM_api('Task_setType', [
	'id' => '318',
	'type' => '3',
]);

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"}ID is absent or below 1.

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

Behaviour and edge cases

  • Writes the integer-coerced type and refreshes last_edited. Omitting type silently resets it to zero.
  • The update has no existence or deletion check, and no task-type lookup.

Side effects

  • Invalidates the task cache. No field history or notifications are created.

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 layouts save mapped type through Task_updateData.

Related endpoints