Delete every file for a resource

When to use this endpoint

Use Files_deleteAll only when removing all attachments from a known resource. For selected IDs use File_delete individually.

Authentication and permissions

The request must authenticate with signed API-key fields or a logged-in CRM session and establish the tenant database context.

The handler performs no record-owner or resource-specific permission check. CRM screens may hide the action, but callers with tenant API/session access can target any matching file ID.

Parameters

Parameter	Type	Required	Description
`type_id`	Integer-compatible	Yes	Positive linked resource ID.
`type_enum`	Integer-compatible	No	Defaults to `0` (Customer) when absent. Common verified values are `0` Customer, `1` Asset Type, `2` Asset, `3` Job, `4` User, `5` recurring Job, `6` User photo, `7` report-design image, `8` Job form photo, `9` report PDF background, `10` private/non-downloadable, `11` form file, `12` Quote, and `13` email-template image. Other modules use later values; use the enum already emitted by the relevant CRM workflow.

Example request

$result = FM_api('Files_deleteAll', ['type_enum' => '2', 'type_id' => '1042']);

Example response

{
  "ok": 1
}

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: type_id"}`	Resource ID is absent or non-positive.

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

Behaviour and edge cases

Per-file failures are discarded and deletion is not atomic. The route ignores each File_delete return value and always reports success after the loop. Earlier files remain removed if a later deletion fails; current File_delete behavior physically removes bytes and rows.

Only rows that are live when the initial ID query runs are selected. Each call performs its type-specific parent-list rebuild/logging, which can repeat work many times.
There is no pagination, upper bound, transaction, or final verification. An empty match also returns success.

See it in Fieldmotion

CRM1

No direct current CRM1 caller was found; screens normally delete one row at a time.

CRM2

No direct current CRM2 caller was found; the generic bulk framework uses Files_delete.

Related endpoints

File_delete performs each deletion.
Files_delete bulk-soft-deletes metadata but does not run these lifecycle side effects.