Requisition orders
Restore a deleted requisition header
/a/RequisitionOrder_restore
Restore a retained header from the authenticated tenant’s deletion history.
When to use this endpoint
This is an Admin-console restoration path. A normal CRM login or signed API key alone does not satisfy its login-source check.
Authentication and permissions
Requires an authenticated tenant identity whose session login_source is admin-console. Merely owning an API key or being a CRM client administrator is insufficient.
Lookup and writes use the current tenant; this helper adds no Requisition page/record/department check.
Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
id | Integer-compatible | Yes | Positive header ID with deleted=1. |
Example request
$result = FM_api('RequisitionOrder_restore', [
'id' => '1042',
]);
Example response
{
"ok": 1,
"type": "requisition_order",
"id": 1042,
"label": "Requisition Order #1042 (Materials for north site)",
"summary": {
"type": "requisition_order",
"id": 1042,
"description": "Materials for north site",
"name": "Materials for north site"
}
}
summary includes nonblank description/attention and a derived name where available; label uses that name. The example has no attention.
Errors and unusual responses
| Response | Condition |
|---|---|
{"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<1. |
{"error":"admin console login required"} | Authenticated login source differs. |
{"error":"deleted requisition_order not found"} | No retained deleted header. |
Legacy application errors may be returned with HTTP 200. Check the decoded response for error, not only the HTTP status.
Behaviour and edge cases
- Requires session login_source exactly admin-console; it does not add a separate client-admin role check. Normal CRM/API identities receive admin console login required.
- Only the retained header is restored; lines/allocations/status/approval/timestamps are not rebuilt or reset. Repeating on an already active row returns a not-found error.
- Marks the latest matching deletion-log metadata restored, with actor/time/function. The header write and audit update are not wrapped in a checked transaction.
Side effects
- Clears header deleted/ddate and invalidates cache. Updates the latest matching deletion audit’s restored metadata; no Job/Purchase Order effects or mapped notifications.
See it in Fieldmotion
CRM1
No direct ordinary CRM1 caller was found; restoration is an Admin-console workflow.
CRM2
No direct ordinary CRM2 caller was found; a normal CRM2 session cannot call this successfully.
Related endpoints
RequisitionOrder_delete— Retain the header before restoration.RequisitionOrder_get— Read the restored header.