(v1.0) LS Central member API (1.0.0)

Read-only projection of the item lines on a wish list. Line mutation (insert, update, remove) is not available through this part — it is done exclusively through the itemModify and modifyQtyUsed bound actions on the parent wishLists entity, which carry the same validation and response codes as the legacy WishListItemModify/WishListModifyQtyUsed SOAP web services.

Read-only projection of the member/card links on a wish list. Link mutation (insert, update) is not available through this part — it is done exclusively through the linking bound action on the parent wishLists entity, which carries the same validation as the legacy WishListLinking SOAP web service. Note: owner here is a Boolean ownership flag — a different meaning than the derived owner name Text field on the parent wishLists entity. cardNo is filterable and is the intended way to look up which wish lists a given card is linked to: query this entity with $filter=cardNo eq ''...'' to get the matching wish list numbers, then follow up with a wishLists?$filter=no in (...) call (optionally adding $expand=wishListLines,wishListLinks for full detail) to retrieve those wish lists.

Exposes member wish lists — header, item lines, and member/card links — as an OData v4 entity, replacing the legacy WishListGet/WishListCreate/WishListDeleteByID/WishListItemModify/WishListLinking/WishListModifyQtyUsed SOAP web services (all six remain available unchanged for the duration of the coexistence window). All reads and writes delegate to the same "LSC Wish List Service" facade the legacy services use, so persisted results and validation match exactly. Six behaviors are non-standard for a REST API and are called out here so consumers are not surprised: (1) GET wishLists(id) is a MUTATING read — fetching a single wish list by id increments its noOfTimesVisited counter, exactly as the legacy WishListGet.GetWishListByID does; a list GET (no key) does not increment. A PATCH wishLists(id) (rename) resolves the entity via the identical key-based fetch as GET wishLists(id) — there is no separate code path that binds fields before that fetch runs — so a successful PATCH also increments noOfTimesVisited, in addition to persisting the name change; live HTTP testing confirmed (reproducibly, twice) this is by +3 per PATCH, not +1, because BC''s real OData PATCH-by-key pipeline performs multiple internal record fetches (key resolution, If-Match/ETag validation, response-body construction), each independently triggering the same mutating-read side effect as a GET. The exact magnitude (3, on this platform version) is a platform implementation detail, not a guaranteed, stable API contract — callers should not hard-code an assumption of exactly 3, only that the counter advances by more than the single-GET amount on a rename. This is expected, accepted behavior, not a bug; callers should not be surprised to see the counter advance on a rename. (2) Creation is a TWO-CALL model: POST wishLists creates the header plus a single owner link from the required cardNo input, then item lines are added afterwards via the itemModify action — there is no single-call deep-insert of lines. (3) The lines and links parts are READ-ONLY projections ($expand only); all line and link mutation is done exclusively through the itemModify and linking bound actions, which carry the same validation and response codes as the legacy operations. The linking action''s status parameter is passed as a plain string matching one of the enum value names — Requesting, Active, Blocked, or Remove — not an OData enum member. (4) The word "owner" means two different things on two different entities: on the header, owner is a derived Text name of the wish list owner (read-only); on a link, owner is a Boolean ownership flag. They are separate OData entity types so there is no schema collision, but callers should not assume the same shape. (5) PATCH is allowed (ModifyAllowed = true) but ONLY name is actually mutable this way — renaming an existing wish list mirrors the interactive Wish List Card page, which has always allowed editing Name post-creation. calculationType and cardNo are both writable ONLY at create time (POST), via a conditional Editable flag that switches to false the moment the record is fetched for view/modify (OnAfterGetRecord) — so neither is actually changeable via PATCH, even though the entity as a whole now accepts it. (6) To find all wish lists linked to a given membership card, do NOT attempt a single-call $filter on this entity for a linked card — Business Central OData v4 has no lambda/any() support, so filtering a header entity by a field on a related child entity in one call is not possible. Instead use a two-call pattern: first GET wishListLinks?$filter=cardNo eq ''...'' to retrieve the matching wish list numbers, then GET this entity with $filter=no in (...) using those numbers (this requires the $schemaversion=2.1 query parameter — e.g. ?$schemaversion=2.1&$filter=no in (...) — omitting it causes BC to reject the request with ''The OData filter expression is not supported'') — add $expand=wishListLines,wishListLinks to the same call for full detail (lines and links), or omit it for a headers-only result.

Read-only replacement for the SOAP GetCrossSelling operation, which remains available unchanged. Both storeNo and originalItemNo are required scoping inputs; only the eq operator with a single literal value is supported on either - any other operator errors, naming the field. Omitting either required filter raises an error (400 Bad Request) - it does NOT return an empty collection. itemNo is the cross-selling item found for originalItemNo, the item asked about. Results are already filtered to items distributed to storeNo. An unknown storeNo or originalItemNo raises an error carrying the legacy SOAP message verbatim, which also surfaces as 400 Bad Request - not 404 - because BC OData cannot return distinct HTTP status codes from AL Error() calls. id is generated per request - it is not a stable identifier and must not be used for change detection or as an etag.

This entity exposes Member Attribute setup — the reusable attribute definitions (code, description, data type, default value, and whether the attribute is mandatory) used to capture custom member data — as a read-only OData v4 entity, replacing the generic RetailWebServices GET_TABLE_DATA reflection-based read of table "LSC Member Attribute" for LS Omni (the legacy SOAP service remains available unchanged for the duration of the coexistence window). This is a read-only projection: Insert, Modify, and Delete are not supported over the API — attributes continue to be maintained through the LS Central back-office UI.

This entity exposes Member Device registrations — the devices (e.g. mobile apps) registered against a member for authenticated self-service access, including status (Active/Blocked) and blocking details — as a read-only OData v4 entity, replacing the generic RetailWebServices GET_TABLE_DATA reflection-based read of table "LSC Member Device" for LS Omni (the legacy SOAP service remains available unchanged for the duration of the coexistence window). This is a read-only projection: Insert, Modify, and Delete are not supported over the API — devices continue to be maintained through the LS Central back-office UI. IMPORTANT: securityToken carries the device''s live authentication credential. This projection exposes it at parity with the legacy SOAP service, which already exposed the same value via reflection, for the duration of the coexistence window. This codebase currently has a single all-encompassing permission set (LSCentralPermissions) with no narrower grant available for this page alone; assigning that set to an integration principal grants broad LS Central access, not just device-read access. Treat assignment of this permission set as a high-trust grant, not a scoped one, until a dedicated narrower permission set exists.

This entity exposes the member loyalty point ledger — the point sale, redemption, expiry, positive and negative adjustment, and transfer entries of a membership card, with their source document, point and remaining-point amounts, expiration date, and the club, scheme, store and POS terminal they originated from — as a read-only OData v4 entity, replacing the generic RetailWebServices GET_TABLE_DATA reflection-based read of table "LSC Member Point Entry". The legacy SOAP service remains available unchanged for the duration of the coexistence window. This is a Phase 1, read-only entity: Insert, Modify and Delete are not supported over the API. Point entries are generated by LS Central''s own point posting routines — POS transaction, sales invoice, credit memo, customer order and point journal posting — and by expiration and point-transfer processing; writing them directly over the API would bypass the point register and remaining-point bookkeeping those routines maintain. All 26 columns of the source table are projected, so every field list a GET_TABLE_DATA caller can request today is available here (31 properties in total, once the id/lastModifiedDateTime system fields and the three ordinal companions below are counted). The legacy GET_TABLE_DATA operation serializes its Option/Enum fields as their numeric ordinal, while this OData entity serializes sourceType, entryType and pointType by member name (platform behavior for OData). To let a consumer migrating off GET_TABLE_DATA keep an ordinal-based mapping, sourceTypeOrdinal, entryTypeOrdinal and pointTypeOrdinal are also projected alongside their named counterparts; these three are computed in memory per row and are not filterable or sortable over OData — filter and sort on the named field instead. This is a transactional ledger that grows without bound, so callers are expected to scope every request: normally $filter on cardNo or accountNo, optionally narrowed by date, with $top for paging. An unfiltered GET returns the entire ledger.