The app carries no organization configuration of its own. Everything that varies by organization is a record on the server, read at run time. This page lists those records so an administrator knows where a change has to be made.
Quick sign-in
The base setting record (setting, name base-setting) carries passcodeLoginSettings:
passcodeLoginSettings: {
enable: true,
mode: "passcode" // or "instant"
}The app fetches it with GET /repository/find-by-attribute/setting/name/base-setting when the quick sign-in screen opens. passcode requires a PIN with a card tap; instant accepts a registered card alone. See staff and access.
Locations
location records, listed with POST /repository/find/location. The location's name slug is what the app sends as businessLocationId on every scoped request. Create locations before staff sign in; the operations screens are empty without one selected.
Payment gateways
GET /storefront/payment-gateways returns the gateways configured for the organization, each with its provider name and public key:
| Provider | Public value returned |
|---|---|
StripeProvider | Publishable key |
PayPalProvider | Client id |
HelcimProvider | Public token |
Card-present payment through a reader or Tap to Pay needs Stripe with Terminal enabled and at least one Terminal location; the app can create one for a business location with POST /storefront/stripe/terminal/location/ensure. See payments.
Receipt and check templates
The receipt layout is not in the app. GET /storefront/pos/tab/:id/receipt-payload returns print primitives already rendered from the organization's posReceiptCustomerTemplate setting, falling back to a factory default. Change the template in Studio Manager and every device prints the new layout on its next receipt. See printing.
Workflows
The pipelines the app shows are workflow definitions. Seven templates are created automatically on first use — including prep-pipeline for the kitchen and reservation-checkin-pipeline for the queue — so a new organization needs no setup to fire an order or seat a guest. Each stage's notification templates and SLA are edited on the definition. See check-in workflow.
Notification senders and copies
systemEmail, systemPhone, systemSmsPhone and notificationCopyTo on the base setting decide the from-address, the SMS number and who receives owner copies. See notifications.
Rate limiting
The backend applies a global limit per client address: 15-minute window, RATE_LIMIT_MAX requests (default 10,000), with standard rate-limit headers. Preflight requests and the health check are exempt. A device that trips it receives 429 until the window rolls over; the app surfaces that as a failed request rather than retrying.
A busy venue with many devices behind one NAT address shares the budget. Raise RATE_LIMIT_MAX on the server if a large deployment starts seeing 429s; TRUST_PROXY_HOPS (default 2) controls which address the limiter sees behind a proxy.
The storefront controller is marked public at the class level, so the POS tab, settle, refund, receipt, service-point-status and take-payment routes accept requests without a token; identity is attached when a token is present but is not required. Only creating categories is role-gated. Treat the backend's network placement and the rate limiter as part of your security posture until those routes are individually gated.
What the app does not read
- No feature flags per organization.
- No remote home layout — which tiles appear is decided per device.
- No theme or branding — the app looks the same for every organization.