System notifications and warnings

Enterprise real-time analytics with BigQuery

Table reservations and booking management

AI-powered booking table optimization

Location booking settings and configuration

Guest user search and creation for bookings

Booking waitlist management

Time slot capacity configuration and limits

Sales channels (dine-in, takeaway, delivery)

Multi-course meal sequencing

Labels and categorization

Company-Wide Items (CWI) management via EAN

Real-time data streaming and sync

Extended waiting times during busy periods

Menu items, products, and modifiers

Invoice management, recipients, and location settings

Floor plans and seating layouts

Location management and creation

Customer loyalty programs, points, tiers, and rewards

Menu structure and organization

Notes attached to tabs and orders

Customer orders and order management

User payment methods management

Permission registry and management

Print template management for receipts and tickets

Receipt and ticket printer management with CloudPRNT URLs

Simplified endpoints for external integrations — place orders without complex setup

Purchase history and transaction details

Purchase summary reports and financial reporting

Customer reviews and feedback for purchases

Role management with permission assignment

Operating hours and special schedules

Tab settlements and payment groupings

Sales statistics, time series, and aggregated data

Table grouping and floor plans

Restaurant table management

Customer tabs and running bills

Payment terminal management

Available time slots for orders and bookings

Multi-language translations for inventory and menus

Product options and modifiers

Discount vouchers and promotions

Webhook subscriptions and event notifications

If your restaurant manages voucher codes in your own system, Karma can forward voucher operations to your URLs instead of Karma's native voucher store. You implement three HTTPS endpoints; Karma calls them as a guest applies a voucher code at checkout.

When this is used

A Karma operator enables the custom voucher provider on a specific restaurant location. The restaurant (or the restaurant's IT vendor) owns the voucher database, and Karma becomes the point-of-sale client that asks your system whether a code is valid and then tells you when to consume it. Karma supports multiple voucher provider types; this document covers the custom type only.

Lifecycle

1. The guest enters a voucher code at checkout. Karma calls your check endpoint to validate and reserve.
2. The guest pays. Karma calls your commit endpoint to consume the voucher.
3. The guest cancels or payment fails. Karma calls your reactivate endpoint to release the reservation.

What you implement

Three HTTPS endpoints of your choosing. The URLs do not need to share a hostname, a path prefix, or a deployment. You give Karma three absolute URLs when the integration is configured.

What you don't need

No inbound callbacks to Karma. No HMAC request signing (Karma does not sign outbound requests today). No Karma-specific SDK, library, or client certificate. Plain HTTPS, JSON in, JSON out, optional Basic Auth or custom header auth.

What you do need

Idempotency on commit and reactivate — if Karma retries a request with the same transactionId, your endpoint must not double-consume the voucher. See Idempotency below.

Authentication & security

HTTPS required. Every URL you give Karma must begin with https://. Plain http:// URLs are rejected by Karma's SSRF guard at request time. Karma also blocks URLs that resolve to private or loopback addresses (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, ::1, fe80::/10, plus IPv4-mapped IPv6 forms of any of the above). Auth modes (pick one per integration):

Mode	Karma sends	You verify
none	No Authorization header	Use only if your endpoints are IP-restricted
basic	Authorization: Basic base64(username:password)	Compare decoded credential to your stored value
headers	Any custom headers you configured (e.g. X-Api-Key)	Compare each header value to your stored secret

Auth credentials (passwords, header values) are stored encrypted at rest (AES-256-CBC) and decrypted in memory only when a request is about to be sent. They are never written to logs. No HMAC signing yet. Karma does not currently sign outbound requests. Authentication relies on HTTPS plus the Basic or header mode you configured. If your compliance requirements call for HMAC-SHA256 request signatures, raise it with Karma support.

Idempotency & retries

Karma automatically retries on:

• HTTP 5xx responses (500/502/503/504 etc.)
• Timeouts (5-second per-request budget)
• Network errors (ECONNREFUSED, ECONNRESET, ENOTFOUND, ECONNABORTED)

Karma does not retry on 4xx — those are treated as definitive rejections. Retry count: up to 2 retries (3 attempts total worst case), no backoff. Every commit and reactivate request carries a transactionId in the body. Your endpoint MUST dedupe by this value — if you receive the same transactionId twice, return the same success body without making any additional change. A unique constraint on transactionId in your database is the simplest way to make this race-free. transactionId format: res_<32 hex chars> (max length 100). The same transactionId is used for both commit and reactivate of a given reservation.

All money in cents

All monetary values are integers in cents. Never return fractional values. Always emit integer cents for discountAmountCents and amountCents; fractional values produce undefined behavior downstream.

Reference implementation

A minimal Node.js + Express server implementing all three endpoints lives in custom-integrations/voucher-provider.md on GitHub.

If your restaurant runs its own loyalty program, Karma can forward member identification, point accrual, and reward redemption to your URLs instead of Karma's native loyalty system. You implement six HTTPS endpoints; Karma calls them across a guest's loyalty lifecycle.

When this is used

A Karma operator enables the custom loyalty provider on a specific restaurant location. The restaurant (or its IT vendor) owns the loyalty database, and Karma becomes the point-of-sale client that asks your system who a member is, how many points they have, and what they can redeem. Karma supports multiple loyalty provider types; this document covers the custom type only.

Lifecycle

1. A guest identifies at the till (scans a card, enters a phone number). Karma calls lookup.
2. A new guest signs up. Karma calls enroll to register them in your program.
3. After a successful purchase, Karma calls award to credit points.
4. The guest opens their loyalty screen. Karma calls account to show balance and tier.
5. The guest browses rewards. Karma calls rewards to list what they can claim.
6. The guest taps a reward. Karma calls redeem to spend their points.

What you implement

Six HTTPS endpoints of your choosing. The URLs do not need to share a hostname, a path prefix, or a deployment. You give Karma six absolute URLs when the integration is configured.

What you don't need

No inbound callbacks to Karma. No HMAC request signing (Karma does not sign outbound requests today). No Karma-specific SDK, library, or client certificate. Plain HTTPS, JSON in, JSON out, optional Basic Auth or custom header auth.

What you do need

Idempotency on award and redeem — if Karma retries a request with the same transactionId, your endpoint must not double-credit or double-spend points. See Idempotency below.

Authentication & security

HTTPS required. Every URL you give Karma must begin with https://. Plain http:// URLs are rejected by Karma's SSRF guard at request time. Karma also blocks URLs that resolve to private or loopback addresses (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, ::1, fe80::/10, plus IPv4-mapped IPv6 forms of any of the above). Auth modes (pick one per integration; applies to all six endpoints):

Mode	Karma sends	You verify
none	No Authorization header	Use only if your endpoints are IP-restricted
basic	Authorization: Basic base64(username:password)	Compare decoded credential to your stored value
headers	Any custom headers you configured (e.g. X-Api-Key)	Compare each header value to your stored secret

Auth credentials (passwords, header values) are stored encrypted at rest (AES-256-CBC) and decrypted in memory only when a request is about to be sent. They are never written to logs. No HMAC signing yet. Karma does not currently sign outbound requests. If your compliance requirements call for HMAC-SHA256 request signatures, raise it with Karma support.

Idempotency & retries

Endpoint	Idempotency requirement	How
lookup	Naturally — it's a read	Same identifier → same memberId
enroll	Recommended	If a request comes in for a userId you already enrolled, return the existing memberId
award	Required	Dedupe by transactionId — must not double-credit
account	Naturally — it's a read	Same userId → current balance
rewards	Naturally — it's a read	Same loyaltyProgramId → current catalog
redeem	Required	Dedupe by transactionId — must not double-spend

Karma retries on: HTTP 5xx, timeouts (5-second per-request budget), network errors (ECONNREFUSED, ECONNRESET, ENOTFOUND, ECONNABORTED). Karma does NOT retry on 4xx — those are treated as definitive rejections, and the response body is dropped. Always signal application errors with HTTP 200 + ok: false + an error.code so Karma surfaces the right code to the UI. Retry count: up to 2 retries (3 attempts total worst case), no backoff. transactionId format: loy_<32 hex chars> (max length 100). A given transactionId is unique to a single operation — award and redeem get different IDs.

All money in cents, points as integers

Monetary values are integers in cents. Point values are whole integers. Always emit integer values; fractional values produce undefined behavior downstream. Round to the nearest whole point on the boundary.

Reference implementation

A minimal Node.js + Express server implementing all six endpoints lives in custom-integrations/loyalty-provider.md on GitHub.

Article and content management

Cost center configuration for accounting

Serving center configuration

API key management