Membership endpoints
“We posted the sale, the member says the points never arrived, and the balance we read back says something else again.” When your own system is the till, the web store or the CRM, that sentence has four usual answers: the document was not the type the company awards on, its lines carried no points, the job that writes them has not run, or your code read the wrong balance endpoint. Members and points behind the endpoints is how your code tells which. These pages cover the HTTP side of BigLedger’s membership module: creating and finding members, writing a points line by hand, reading a member’s balance and ledger, and what runs between a finalised sale and the balance moving.
There is one API for the whole platform and no separate membership API. The path grammar, credentials, paging, envelope and error codes are on the integration path and the authentication page; what follows is what is particular to members and points.
The page for your situation
| Your situation | Open | Why that page |
|---|---|---|
| Your web store enrols a shopper and needs the card the counter will recognise | POST Create Member | The body is the member record. Send no customer and the backend finds one by the sign-in, the phone, then the e-mail, and creates one when none matches |
| A member changed their phone or e-mail on your side | PUT Update Member | The same container, updated in place. The customer record is left as it was |
| You must find a card by number, phone or e-mail before you post a sale | GET Members by Criteria | card_no, phone, email and search_word filters, paged |
| You owe or are taking back points for something that was not a sale: a goodwill gesture, a migration, a correction | POST Create Member Point Transaction | One line, written and queued to the balance at once, with no document behind it. Read the cautions first |
| A member disputes their balance and you need every movement with its date and origin | GET Points Transactions by Criteria | The card’s lines with their dates, page by page; a line written from a sale also names the document and line it came from and the source that wrote it, and a line added by hand carries only what its writer sent |
| Your checkout wants to offer the points a member can spend | GET Points Current Balance | The stored running total, the same row the till reads |
| You need a membership route these pages do not name | Membership endpoint families | Every route is a row in the backend’s route table; the families table names the controller and prefix to look under |
A sale is FINAL and the member’s points never arrived, or two balance reads disagree | Members and points behind the endpoints | What runs after Finalise, the errors and their causes, and a thirty-second check of one card |
The six endpoints documented page by page
| Endpoint | Page |
|---|---|
GET core2/tnt/dm/membership-cards/query | GET Members by Criteria |
POST core2/tnt/dm/membership-cards | POST Create Member |
PUT core2/tnt/dm/membership-cards | PUT Update Member |
POST core2/tnt/dm/crm/membership-points-txn/txn-line/backoffice-ep | POST Create Member Point Transaction |
GET core2/tnt/dm/crm/membership-points-txn/backoffice-ep/lines/query | GET Membership Points Transactions by Criteria |
GET core2/tnt/dm/crm/membership-points-txn/current-balance/query | GET Membership Points Current Balance |
Every sample on those pages uses synthetic GadgetSphere data (cards GS-0001234…, point currency
GSPTS, tenant gadgetsphere).
What happens after you finalise a sale with a member on it
Finalise queues one job and answers. Whether points are then written depends on the tenant’s
subscriptions, the member on the header, the company’s MEMBER_POINT configuration and the points on the lines, and the writer
says nothing when it declines.
Members and points behind the endpoints
walks the six steps, and Membership endpoint families
says which of the two balance calls is the figure the till shows.