Platform

The infrastructure behind the storefront.

One backend powers Backoffice, POS and Guests — the same OAuth2, REST and SignalR services underneath every screen. Real-time by default, multi-tenant by sub-merchant, and open at the edges through a Partner API and outbound webhooks. Serious enough to run more than one site.

Quivi backend live
Backoffice synced
POS synced
Guests synced
SignalR ·Webhooks ·Partner API

The problem

A stack of apps that don't talk, integrations you babysit, and data that quietly drifts

Most hospitality stacks are three vendors stapled together — a POS here, a QR ordering tool there, a payments box that syncs on a schedule. The seams are where you lose money and trust.

Menus out of sync

The price you changed on the till never reaches the QR menu the guest is looking at.

Integrations you maintain

Every connector is one more thing that breaks on a Friday night and lands on you.

One site is the ceiling

Adding a second location means a second stack, second logins, and reconciliation by hand.

Live sync

Change it once — it's everywhere before you look up

When an entity changes, SignalR pushes a cache invalidation and every connected app re-fetches on its own. No export, no refresh, no waiting.

Make a change

Quivi backend live
Backoffice config Burrata €12.00
POS staff Burrata €12.00
Guests QR app Burrata €12.00

The spine

The spine underneath every screen.

Four ideas do the heavy lifting: one core, real-time push, tenant isolation, and open edges. Everything else is built on top of them.

  1. 01 Core

    One core behind every screen

    Backoffice, POS and Guests share the same services — OAuth2, REST and real-time SignalR, with background jobs and an event bus underneath — so there's a single source of truth, not three that argue.

  2. 02 Sync

    Push, don't poll

    SignalR pushes cache invalidations the instant an entity changes, and each app re-fetches automatically. If a device drops off, a ~30-second poll catches it back up.

  3. 03 Isolation

    Multi-tenant by sub-merchant

    Every API call is scoped to the active sub-merchant, so one site never bleeds into another. Add a location as configuration — no new stack to stand up alongside the last one.

  4. 04 Connect

    Open at the edges

    POS integrations, acquirer and delivery configs, a dedicated Partner API and outbound webhooks — the platform plugs into what you already run instead of walling you in.

What you're actually buying

Infrastructure you can build a business on.

A proper multi-tenant platform you can connect to, pair devices against, and run across more than one site.

One backend, three apps

Backoffice for config, POS with a built-in KDS mode, and the QR Guests app — one set of shared services underneath, from auth to real-time to ESC/POS printing.

Real-time via SignalR

Cache invalidations are pushed on every entity change and apps re-fetch instantly — a guest's QR order lands on the POS and kitchen live, with a ~30s polling fallback.

Multi-tenant by sub-merchant

Every request is scoped to the active sub-merchant, so one site never leaks into another — run a single location or a whole group on the same backend.

OAuth2, JWT & device pairing

A custom Quivi.OAuth2 server on ASP.NET Identity issues OAuth2 + JWT with automatic refresh. POS devices pair with a device-authorization code from Backoffice, then run on a JWT with no re-login.

Integrations, Partner API & webhooks

Quivi-native or Facturalusa POS integrations, acquirer configs (Cash, Paybyrd, Revolut Pay, MB Way) and delivery — plus a separate Partner API and outbound webhooks for BI and aggregators.

PT/DK fiscal compliance

Live in Portugal and Denmark with locale-aware NIF/CVR validation, postal codes and currency, invoicing via Quivi-native or Facturalusa, and full refund traceability.

Run one site or a whole group — no cross-tenant bleed.

Every API call is scoped to its sub-merchant, and the POS reloads whenever the active tenant changes to keep every cache consistent. Adding a location is configuration in Backoffice, not a second stack to stand up and reconcile.

One backend · many sites · scoped per request

The connective tissue

One backend, every Quivi surface.

Point of Sale, Payments and the AI Assistant aren't bolted-on products — they're surfaces on this same backend, reading the same real-time truth. Configure it once in Backoffice and that's what the floor sells, what the terminal charges, and what the assistant acts on.

See the platform, end to end

Bring your architecture questions — multi-site, auth, webhooks, fiscal. We'll walk the architecture and show how your stack connects.