When to use this endpoint

Use Opportunity_delete for the CRM1 single-row delete action. CRM2’s selection workflow uses Opportunities_delete.

Authentication and permissions

The request must authenticate with signed API-key fields or a logged-in CRM session. The handler performs no additional page or role-permission check.

The lookup and any write use the authenticated tenant; an ID from another tenant cannot be addressed through this call.

Parameters

ParameterTypeRequiredDescription
idInteger stringYesOpportunity ID after integer conversion. Presence is checked, so blank/zero values still return success.

Example request

$result = FM_api('Opportunity_delete', [
	'id' => '481',
]);

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 omitted.

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

Behaviour and edge cases

  • Only a currently non-deleted row is changed. Missing, zero, already-deleted, and foreign-tenant IDs are silent no-ops with the same success response.
  • The handler checks neither the Opportunities feature nor a delete/page permission.

Side effects

  • For an existing row, records its ID/notes in the tenant deletion log, then sets deleted=1 and ddate to the current epoch and invalidates the opportunities cache.
  • In a CRM2 session, queues an opportunity update notification from deleted=0 to deleted=1 even when the requested row was not changed. CRM1/API sessions do not send it.

See it in Fieldmotion

CRM1

The Opportunities table’s single-row delete control calls this route after typed confirmation.

CRM2

The current bulk selection action uses Opportunities_delete, not this route.

Related endpoints