Skip to main content
LIP is an open-source loyalty platform and vendor-neutral transaction protocol for restaurant technology teams. It combines customer data, a marketer workspace, campaigns and attribution, a reference guest wallet, restaurant adapters, and a deterministic checkout engine. Self-host the Apache-2.0 stack or adopt only the portable /lip/v1 contract.

Try in the browser

Run evaluate through refund against synthetic foodservice data. No key or install.

Self-host

Start the Apache-2.0 reference platform with Docker or Node 22.

Design partner

Prove one real ordering integration, migration, and rollback path.

Quick start

Then open Admin with the printed key (lip-local-compose-key-change-me in the local-only Compose profile) and the visibly synthetic guest wallet.
Installed and running? Read Essentials next — it covers the six things every new integrator needs: the order lifecycle, idempotency, the Admin dashboard, the CLI, reset and seed controls, and conformance checks.

Where to go next

Quickstart

From clean clone to a working loyalty request in five minutes.

TypeScript SDK

The idiomatic client: typed errors, exact money, and the order builder.

API Reference

Every endpoint, generated from the checked-in OpenAPI 3.1 contract.

Webhooks

Signed CloudEvents after every successful mutation.

Reference Platform

Server, Admin dashboard, storage, and implementation boundaries.

Platform API

Profiles, consent, events, segments, campaigns, imports, and attribution.

Guest Wallet

A responsive OIDC Authorization Code + PKCE reference BFF.

Protocol Spec

The normative contract: lifecycle rules, profiles, and conformance.

What the protocol covers

  • Complete loyalty lifecycle — member lookup, enrollment, balances, ledger history, order evaluation before checkout, accrual after payment, and redemption reserve, capture, reverse, and refund-safe adjustment flows.
  • Foodservice-first order model — items, modifiers, discounts, fees, taxes, tips, tenders, and totals, with channel-aware rules for counter, drive-thru, kiosk, web, mobile, pickup, delivery, and catering.
  • Retry-safe by design — idempotency keys, request context, RFC 9457 problem details, and partial refund, void, reversal, and duplicate-check semantics.
  • Multiple program models — executable points, visits and stamps, wallet credit, paid membership, and hybrid multi-account programs.