When to use this endpoint

Use ScheduleOfRate_delete only when a map-driven integration deliberately needs filtered hard deletion. For one explicit ID, the older ScheduleOfRates_delete also cleans queued Schedule of Rates integration links.

Authentication and permissions

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

All reads and writes use the authenticated tenant. The CRM screens apply client-side Schedule of Rates permissions, but those controls are not repeated by this endpoint.

Parameters

ParameterTypeRequiredDescription
idInteger string or native arrayRecommendedExact ID filter. A scalar is integer-converted; an array becomes a numeric IN list.
Mapped filtersScalar or native arrayAt least oneAny stored mapped key from name, code, stockUsed, cost, lastEdited, description, meta, metaNominal, metaNominalID, metaNominalCode, metaTaxTypeID, assetTypes, labourUsed, priceBands, archived, and metaCustomerCosts can be supplied. Scalars use exact equality and arrays use IN. Use id; nested metadata filters are not safely implemented by this delete helper.

Example request

$result = FM_api('ScheduleOfRate_delete', [
	'id' => '430001',
]);

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 filter"}No recognized mapped filter is present.
{"ok":1}The filter is valid but matches no row; absence is not reported.
Database errorA nested metadata key such as metaNominalID is used as a delete filter; this helper does not translate its dotted map path to JSON SQL.

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

Behaviour and edge cases

  • Multiple supplied filters are AND-combined. Text is case-sensitive or case-insensitive according to the tenant column collation; it is not a substring search.
  • The table has no soft-delete columns. Archived and active rows are equally eligible.
  • There is no ordering or pagination. The endpoint first selects every matching row so it can record their IDs.

Side effects

  • Hard-deletes matching rows, advances the schedule_of_rates cache marker, writes entries to the tenant deletes log, and records a generic delete audit entry when IDs matched.
  • Unlike ScheduleOfRates_delete, it does not clean Schedule of Rates rows from integration queues and does not fire SOR_edit.

See it in Fieldmotion

CRM1

No direct production CRM1 caller was found.

CRM2

The current bulk-delete flow checks that selected rows are archived, then calls ScheduleOfRates_delete once per ID; it does not use this route.

Related endpoints