When to use this endpoint

Use File_delete for normal single-file deletion from CRM1/CRM2 file screens. It coordinates more related state than the generic Files_delete route.

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

ParameterTypeRequiredDescription
idInteger-compatibleYesPositive ID of a currently non-deleted file.

Example request

$result = FM_api('File_delete', ['id' => '4821']);

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 non-positive.
{"error":"file not found"}No live row matches.

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

Behaviour and edge cases

  • The row is marked deleted=1 with a Unix ddate and current last_edited; stored bytes/archive linkage are cleared and a deletes entry is recorded.
  • Customer and Asset file CSV fields are rebuilt. Job and recurring-Job records receive the remaining live file IDs and updated timestamps; Job edited_uuid becomes File_delete. User-file deletion writes a User audit message.
  • Database, storage, deletion-log, and parent updates are not one transaction. Explicit errors are returned if the metadata, content, or deletion-log step fails.

See it in Fieldmotion

CRM1

Click delete on Customer, Job, Asset, User, Task, Asset Type, recurring-Job, or generic file tables.

CRM2

Use Delete on a modern file row; bulk framework behavior may instead call Files_delete.

Related endpoints