Jobs: lookups and details
Inspect a job’s outsourcing link
/a/Job_isOutsourced
Determine whether a persisted job is an outgoing original, an incoming copy, or has no usable outsourcing link.
When to use this endpoint
Determine whether a persisted job is an outgoing original, an incoming copy, or has no usable outsourcing link.
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. |
job | Native object/array | Legacy internal control | If supplied with job.id equal to the requested id, its user_id/user_type/meta are trusted instead of reading the job. Internal mutation paths pass loaded rows; external callers should omit it. |
Example request
$result = FM_api('Job_isOutsourced', ['id' => '1042']);Example response
{"user_id":1088,"app_id":2042,"type":"original"}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 or nonpositive. |
false | No active job exists, no outsourcing link is present, or required account/job link IDs are nonpositive. |
Legacy application errors may be returned with HTTP 200. Check the decoded response for error, not only the HTTP status.
Behaviour and edge cases
- For user_type=1, returns original with integer user_id and the positive linked job ID from meta.outsourced.id. This branch wins over incoming-copy metadata.
- Otherwise incoming metadata with outsourcing.link_from and outsourcing.id produces copy; both IDs must be positive. user_id in the response identifies the counterpart account, not necessarily a staff user.
- The normal query excludes deleted jobs. A provided job snapshot bypasses that query; the helper also supports an internal request-global preloaded row. It does not check the counterpart account/job actually exists.
- Results are cached by requested job ID for the PHP request. Metadata/row changes later in that request do not automatically invalidate a cached result.
- No cross-account fetch, link repair, notification or other persistence occurs.
See it in Fieldmotion
CRM1
No direct network caller was found. Job and Jobs mutation handlers call this helper internally to decide whether to propagate changes across an existing outsourcing link; inspect the parent request rather than expecting a separate lookup.
CRM2
No direct network caller was found. Shared CRM mutation helpers invoke this route internally; CRM2 does not need a separate request for ordinary job editing.
Related endpoints
Jobs_getByIdreturns raw job assignment/metadata without classifying the link.Job_getCustomerDetailscan use originating-account customer data for an incoming copy.