Retrieve a job’s raw change log

When to use this endpoint

Read raw history for one job and one exact history subtype, including form-field or user-change entries.

Authentication and permissions

Authenticate with signed API-key fields or a logged-in CRM session. These calls use the authenticated account’s data; the handler has no additional job-page, department, assignee or client-admin permission check unless stated below.

Parameters

Parameter	Type	Required	Description
`id`	Integer string	Yes	Job ID, converted with intval; the result must be positive. This selects a physical job ID, not an app ID or job reference.
`type`	String	No	Exact type_name2 value; defaults to the empty string, not all subtypes. Form fields use field_; the assigned-user tooltip uses current_user_id.

Example request

$history = FM_api('Job_logGet', ['id' => '1042', 'type' => 'field_27']);

Example response

[]

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"}`	Invalid ID; checked before login.
`false`	Database query failure rather than no matching history.

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

Behaviour and edge cases

Returns all matching log columns: id, cdate, type_name, type_name2, description, user_id, meta and obj_id. Scalars normally remain database strings; meta remains encoded JSON.
Filters type_name=job, exact subtype and obj_id, with the fixed strict cutoff cdate>1526428800 (Unix seconds). Earlier history is not returned.
Does not verify that the job currently exists or is active; retained logs can outlive a deleted job.
No ORDER BY, pagination or limit is applied. Sort client-side when needed. Descriptions and encoded old/new/IP metadata are not translated or sanitized here.
There are no writes or notifications.

See it in Fieldmotion

CRM1

On a job Form, open History of Changes for a field. jobFormFieldHistoryShow.js sends type=field_. Hovering the current-user detail in the job list uses type=current_user_id through jobUserShow.js.

CRM2

No direct CRM2 caller was found in the reviewed source. For batched job fields, see Jobs_getById.

Related endpoints

Job_formLogGet adds user names and presentation fields, with different parameters and no fixed cutoff.
Jobs_getById reads current values, not history.