Lightspeed Retail (X-Series) MCP by usefulapi

The connected store: id, name, domain prefix, store URL, country, currency, time zone, tax-exclusive setting, loyalty and gift-card settings. Good first call (use the time zone to turn a local day into UTC for sales searches). GET /retailer.

Takes no parameters.

List the store's outlets (locations): id, name, address, currency, time zone, default tax. Use the outlet id to filter sales, stock and stock orders. Paginate with next_after. GET /outlets.

One outlet by id. GET /outlets/{outlet_id}.

List registers (tills): id, name, outlet_id, is_open, open/close times and invoice numbering. Paginate with next_after. GET /registers.

Payment totals by payment type for one register since it was opened (the end-of-day / cash-up view). GET /registers/{register_id}/payments_summary.

List tax groups and their rates (id, name, is_default, rates). The vendor returns the whole list in one reply (no cursor). GET /taxes.

Takes no parameters.

List the store's users (staff): id, username, display name, email, account type (cashier, manager, admin), enabled flag, restricted outlets. Paginate with next_after. GET /users.

Sales totals for one staff user, as the vendor computes them (no date filter; use sales_summary for a period). GET /users/{user_id}/sale_totals.

List products (variants) in the catalog: id, family_id, sku, variant_name, prices (price_excluding_tax / price_including_tax), active flags, codes, suppliers, version. The product NAME lives on the product family: add includes=["families"] to get it. Paginate with next_after (stop when data is empty). With sku set, only that SKU is looked up and the other filters are ignored. For text/brand/supplier filters use search_products; for stock use get_inventory_levels. GET /products.

One product (variant) by id, with its prices, codes, suppliers and outlet taxes. GET /products/{product_id}.

Filter products by SKU, brand, supplier, tag, product type or variant parent. Uses offset paging: pass next_offset to continue (null = last page). GET /search?type=products.

Stock on hand per product per outlet: product_id, location_id (= outlet id), current_inventory_level, reorder threshold/amount, quantity_to_procure, average cost, total cost, supplier. Filter by outlet_ids, product_ids (or root_product_ids for variant families), supplier_ids; to_be_procured_only keeps products with a positive quantity_to_procure (the vendor's re-order suggestion, which accounts for open orders); for a plain below-reorder-point list, compare current_inventory_level with reorder_threshold yourself. Offset paging: pass next_offset to continue (null = last page). Read-only even though the vendor takes the filter as a POST body. POST /inventory_levels.

List product brands (id, name). Paginate with next_after. GET /brands.

List product tags (id, name). Paginate with next_after. GET /tags.

List suppliers: id, name, default markup and contact details. Paginate with next_after. GET /suppliers.

List consignments: supplier stock orders (type SUPPLIER), transfers between outlets (OUTLET), stocktakes (STOCKTAKE) and returns (RETURN), with status (OPEN, SENT, DISPATCHED, RECEIVED, STOCKTAKE_*, CLOSED, CANCELLED), outlet, supplier, due and received dates, totals. Paginate with next_after. GET /consignments.

One consignment (stock order, transfer, stocktake or return) by id. GET /consignments/{consignment_id}.

The product lines of one consignment: product_id, SKU, ordered count, received quantity, cost. Paginate with next_after (stop when data is empty). GET /consignments/{consignment_id}/products.

Sales in version order, oldest changes first: the way to sync everything that changed. It has NO date filter: for a period use search_sales or sales_summary. Each sale: id, date, invoice_number, state, customer_id, source (outlet, register, user), payments, line_items, totals. Paginate with next_after (stop when data is empty). GET /sales.

One sale by id with its line items, payments, taxes and totals. GET /sales/{sale_id}.

Find sales by date range (UTC), state, outlet, register, user, customer, payment type, product or invoice number. Uses offset paging: pass next_offset to continue (null = last page). Replies can be large: for totals over a period use sales_summary instead of paging through this. GET /search?type=sales.

Totals for a period computed here from up to max_pages x page_size sales, so a report needs ONE tool call instead of dozens: sale count and net / tax / gross (tax-inclusive) totals, plus breakdowns by state, UTC day, outlet and payment type name, and the top products by quantity. By default only closed sales are counted (states containing 'closed'); set counted_states to change that. Dates are UTC (convert local days with the retailer's time zone). If the reply says truncated, call again with offset = next_offset and add the figures up. Uses GET /search?type=sales.

List customers in version order: id, customer_code, name, email, phone, balance, loyalty_balance, year_to_date, customer group. To find one by name or email use search_customers. Paginate with next_after (stop when data is empty). GET /customers.

Find customers by email, first name, last name, company name, phone, mobile or customer code. Uses offset paging: pass next_offset to continue (null = last page). GET /search?type=customers.

One customer by id: contact details, addresses, customer group, balance, loyalty balance, year-to-date spend. GET /customers/{customer_id}.

List customer groups (id, name). Use the id as customer_group_id when creating or updating a customer. Paginate with next_after. GET /customer_groups.

WRITE: create a new customer. Give at least a first name, last name or company name. Check search_customers first so you do not create a duplicate. POST /customers.

WRITE: change fields of an existing customer. Only the fields you pass change: the tool first reads the customer and sends the vendor its full record with your changes applied (the vendor's update is a full PUT). Cannot delete a customer or change balances. Lightspeed offers no partial update for customers, so a change made by someone else in the moments between the tool's read and its write can be overwritten. PUT /customers/{customer_id}.

WRITE: set the selling price of one product (variant). Pass price_excluding_tax or price_including_tax as a decimal string such as "24.99" (set one; the store's tax setting decides which the till uses). Nothing else on the product changes. Read the product first and confirm the new price with the user. PATCH /products/{product_id}.

WRITE: set the stock on hand (current_amount) and/or the reorder point and reorder amount of ONE product at ONE outlet. current_amount is the NEW TOTAL on hand, not a change: it overwrites the count, so sales made since you last read it are lost from the count. Read get_inventory_levels first and confirm the number with the user. Other outlets and all other product fields stay as they are. PATCH /products/{product_id} (outlet_inventories).