When to use this endpoint

Use ContractType_delete only after confirming the classification is no longer needed. Both CRM contract-type screens use it after confirmation.

Authentication and permissions

The request must authenticate with signed API-key fields or a logged-in CRM session. No role or delete permission is enforced by the handler; CRM2 hides the bulk action when its client-side delete permission is denied.

The Contracts UI requires tenant feature bit 64, but the endpoint does not.

Parameters

ParameterTypeRequiredDescription
idInteger stringYesPositive contract-type ID. The handler does not verify that a row exists before deleting and clearing references.

Example request

$result = FM_api('ContractType_delete', [
	'id' => '31',
]);

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"}The ID is absent, zero, negative, or nonnumeric.

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

Behaviour and edge cases

  • A missing positive ID still returns success, writes a deletion-log entry, and runs the contract-reference update.
  • Contracts are updated regardless of their deleted/active state. Their last_edited values are not advanced.

Side effects

  • Hard-deletes the type, records contract_types in the tenant deletion log, then sets matching contracts’ type_id to zero.
  • No contract audit rows, notifications, or cache-invalidating contract writes are requested by the second statement.

See it in Fieldmotion

CRM1

Open Contracts → Contract Types, choose the delete link, and confirm. CRM1 warns that affected contracts will have their type unset.

CRM2

Open Contracts → Types, select rows, choose Delete Contract Types, and inspect the per-ID ContractType_delete requests.

Related endpoints