When to use this endpoint

Use for the legacy browser name cache. For a selected set of IDs, use Stock_listByIds; do not treat this as a deletion feed.

Authentication and permissions

Authenticate with signed API-key fields or a logged-in CRM session. The handler calls the user-login guard but adds no stock-page, finance or administrator permission check.

Queries use the authenticated tenant. Sign numeric values as strings; JSON-encode only parameters described as JSON text. See Getting started.

Parameters

ParameterTypeRequiredDescription
last_editedDatetime stringNoOmitted, blank or falsey (including string "0") selects full-load mode. Otherwise compares stored last_edited strictly greater than the supplied text and strictly less than the current server datetime; no date validation.

Example request

$names = FM_api('Stock_getNames', ['last_edited'=>'2026-09-24 14:30:00']);

Example response

[{"id":"1042","name":"Filter cartridge","last_edited":"2026-09-24 15:00:00"}]

Incremental example. Full loads return id/name and put a date-only last_edited on just the final returned row. With no rows, both modes return [].

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.
[]No active stock matches the selected interval.

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

Behaviour and edge cases

  • Excludes deleted rows but includes archived stock. No paging, ordering or department/owner restriction.
  • Full-load final-row checkpoint is the current server date, not that row’s edit datetime. The row chosen as final is not explicitly ordered.
  • Incremental bounds are exclusive. Edits at the supplied boundary or current second are not returned; null edit timestamps do not satisfy the interval.
  • Only incremental rows include their real last_edited values. There are no delete markers, so removing a cached stock item requires a separate deletion/polling flow.
  • No direct mobile caller was found in the current app JavaScript or m/www intermediary. The app receives stock through syncDownloads, which selects non-deleted stock by edit timestamp; these calls are not the app synchronization protocol.

Side effects

  • Read-only; no audit, edit timestamp, event or stock movement.

See it in Fieldmotion

CRM1

Browser bootstrap reads its IndexedDB stocks cache and posts Stock_getNames with lastEdit; stocksUpdate consumes the returned names/checkpoint. Filter Network when starting CRM1 or rebuilding the local browser cache.

CRM2

CRM2 header bootstrap likewise posts to Stock_getNames using its cached lastEdit, via the configured API server. This is separate from the Stocks module table.

Related endpoints