Fieldmotion API Getting started

Goods Received

List legacy receipt IDs

POST /a/PurchasesIn_list

Enumerate receipt headers for legacy maintenance or follow-up reads.

When to use this endpoint

Enumerate receipt headers for legacy maintenance or follow-up reads.

Authentication and permissions

Authenticate with signed API-key fields or a logged-in CRM session. Session CSRF, account-active and IP restrictions still apply. These handlers add no receipt-specific page, finance, department or record-owner permission check.

Records are scoped to the authenticated tenant. CRM1 displays Goods Received with employer feature bit 262144; CRM2 checks features2.goodsReceivedNotes. Those screen gates are not enforced by these handlers. Mobile receipt routes run separately through the mobile intermediary and have different permission and ownership checks.

Parameters

This endpoint has no operation-specific parameters.

Example request

FM_api('PurchasesIn_list', []);

Example response

{"ok":1,"list":[{"id":"531"},{"id":"532"}]}

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.

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

Behaviour and edge cases

  • Selects only id from every purchases_in header. No pagination, ordering, supplier/date/status or owner filtering. An empty table yields list:[]; a failed read can yield list:false while ok stays 1.
  • No linked-line or stock checks and no writes. The name refers to Goods Received headers, not purchase orders.

See it in Fieldmotion

CRM1

No production CRM1 caller was found. API-test cleanup uses this ID list; the user-facing list is GoodsReceived_getDT.

CRM2

No production CRM2 caller was found; its page uses GoodsReceived_getDataTable.

Related endpoints