Resolve a customer from one child

When to use this endpoint

Use Customer_getByChild only when a caller has one local child ID plus its legacy type code and needs the related customer record.

For a batch of mixed jobs, assets, quotes, invoices, and other child records, use Customers_getByChild.

Authentication and permissions

The request must establish tenant context with signed API credentials or a logged-in CRM session. The handler checks for DBP rather than calling the normal login helper.

No additional page or role permission is checked.

Parameters

Parameter	Type	Required	Description
`id`	Integer string	Yes	Local child customer or asset ID.
`type`	Integer string	Yes in practice	`0` treats `id` as a child customer; `1` treats it as an asset. Omission currently falls through as type `0`, but callers should send it explicitly.

Example request

$parent = FM_api('Customer_getByChild', [
	'id' => '2088',
	'type' => '1',
]);

Example response

{
  "id": "1042",
  "name": "Northwind Service Centre",
  "is_active": "1"
}

The example shows only representative fields. On success the response is the broad default Customer_get object, not a wrapper: it includes every allowed stored field except contacts. See that endpoint for the exact field list and scalar/JSON encoding.

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 not positive.
`false`	The child is missing, has no usable customer relationship, or `type` is unsupported.

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 type 0, the endpoint reads the child customer’s parent_id.
For type 1, an asset at a customer location uses location_id; all other assets use owner_id.
Child lookups do not filter soft-deleted rows. The final customer retrieval follows Customer_get behavior.
There is no ordering or pagination because only one relationship is resolved.

See it in Fieldmotion

CRM1

No production CRM1 caller was found; the behavior is retained for compatibility and is covered by API tests.

CRM2

No production CRM2 caller was found. CRM2 list pickers generally request customer details directly.

Related endpoints

Customers_getByChild resolves a batch of several supported child types.
Customer_get defines the returned customer object.