When to use this endpoint

Use for an explicit ID batch. Each ID uses the same checked deletion helper as Job_delete; the batch itself is not one transaction.

Authentication and permissions

Requires an authenticated API-key/session context. Delete bit 16 is enforced with the same client-admin exception as Job_delete.

Each primary job is scoped to the authenticated tenant. There is no extra department/owner/finance guard.

Parameters

ParameterTypeRequiredDescription
idsJSON-encoded arrayYesJSON string, not native array. Integer-coerces and deduplicates; nonpositive IDs rejected before writes. [] succeeds without work.

Example request

$result = FM_api('Jobs_delete', ['ids' => json_encode(['1042', '1088'])]);

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 parameter: ids"}Omitted field.
{"error":"parameter \"ids\" should be an array in JSON form"}Not a JSON-encoded array.
{"error":"missing or invalid parameter: ids"}A normalized ID is nonpositive.
{"error":"no such job exists"}Missing physical row; response also includes failedId/updatedIds.
{"error":"insufficient CRM permissions"}Delete bit 16 set without admin exception.

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

Behaviour and edge cases

  • Processes deduplicated IDs in input order through the single-job deletion helper. Active rows are soft-deleted; already-deleted rows are no-ops.
  • Local row/audit/relation cleanup is atomic PER JOB, not across the batch. The first error returns failedId and updatedIds for the successfully processed prefix; missing rows no longer disappear silently.
  • Removes all supported quote, primary/ancillary invoice, contract and task links and refreshes their cached counts consistently with Job_delete. Movement history remains.
  • Recurrence membership is detached and empty sequences retained inactive. Customer/cron/remote/CRM2 notification follow-ups run after each local commit; saved warnings are collected.
  • No batch size cap or batch rollback. A saved warning signals committed work even when a follow-up could not be confirmed.

Side effects

  • Same local deletion audits, link cleanup, scoped recounts and retained-history policy as Job_delete.
  • Same post-commit customer, recurrence, cron, outsourcing and CRM2 notification follow-ups per job; warnings do not roll back saved deletion.

See it in Fieldmotion

CRM1

No production direct caller was found. Jobs multi-delete iterates Job_delete. API test cleanup uses Jobs_delete, which is not evidence of a UI bulk-delete contract.

CRM2

No direct caller was found. Jobs module/editor deletion resolves to Job_delete, including per-row import rollback.

Related endpoints