White-label Guest App

The Innovorder Guest App serves employees and other diners in collective catering. Each enterprise deployment has its own Innovorder brand and published hostname. A catering operator can serve several enterprise deployments; a diner can only access their own brand and the restaurants configured for that deployment.

This page documents the built-in Guest App API. The third-party integration guide covers a separate service-account integration pattern. All identifiers and example hostnames below are fictional. Provider credentials and deployment activation must be provisioned before the corresponding features are available.

https://guest-embed.innovorder.io/embed/11111111-1111-4111-8111-111111111111/menus
https://cantine.customer.example/embed/11111111-1111-4111-8111-111111111111/menus

Dev: guest-embed-dev.innovorder.io
Preproduction: guest-embed-preprod.innovorder.io

{
  "iss": "urn:innovorder:guest-embed:integration:22222222-2222-4222-8222-222222222222",
  "aud": "urn:innovorder:guest-embed:11111111-1111-4111-8111-111111111111",
  "iat": 1791194400,
  "exp": 1791194460,
  "jti": "44444444-4444-4444-8444-444444444444",
  "module": "menus",
  "parentOrigin": "https://portal.customer.example",
  "targetOrigin": "https://guest-embed.innovorder.io",
  "badgeNumber": "0000123456"
}

// Partner server: run after your user authentication and CSRF middleware.
// Derive customerId from your trusted user-to-Innovorder mapping.
import jwt from 'jsonwebtoken';
import { randomUUID } from 'node:crypto';
const now = Math.floor(Date.now() / 1000);
const autoLoginJWT = jwt.sign({
  customerId: authenticatedInnovorderCustomerId,
  module: 'menus',
  parentOrigin: 'https://portal.customer.example',
  targetOrigin: 'https://guest-embed.innovorder.io',
  iat: now, exp: now + 60, jti: randomUUID()
}, serverSecrets.guestEmbedKey, {
  algorithm: 'HS256', keyid: '33333333-3333-4333-8333-333333333333',
  issuer: 'urn:innovorder:guest-embed:integration:22222222-2222-4222-8222-222222222222',
  audience: 'urn:innovorder:guest-embed:11111111-1111-4111-8111-111111111111'
});
// Return { autoLoginJWT } with Cache-Control: no-store to that user only.

<script src="https://guest-embed.innovorder.io/embed-sdk/v1.js"></script>
<div id="guest"></div>
<script>
const guest = GuestAppEmbed.mount(document.getElementById('guest'), {
  url: 'https://guest-embed.innovorder.io/embed/11111111-1111-4111-8111-111111111111/menus',
  integrationId: '22222222-2222-4222-8222-222222222222',
  locale: 'fr',
  getToken: async (context) => {
    const response = await fetch('/api/guest-embed-token', {
      method: 'POST', headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(context)
    });
    if (!response.ok) throw new Error('Authentication unavailable');
    return (await response.json()).autoLoginJWT;
  },
  onEvent: (event) => { /* Update host loading/error UI. No credentials or balance amounts. */ }
});
// guest.setLocale('en'); guest.setRestaurant(200); guest.navigate('/menus');
// guest.logout(); // Stops automatic authentication; mount again for a new login.
// guest.destroy();
</script>

{
  "revision": 0,
  "approvalMode": "manual",
  "advanceDays": 30,
  "guestCancellationEnabled": true,
  "cancellationCutoffMinutes": 120,
  "contactEmail": "restaurant@example.org",
  "notifyContact": false,
  "location": "10 Example Street, Paris"
}

{
  "revision": 0,
  "startsLocal": "2026-11-12T12:00",
  "endsLocal": "2026-11-12T13:30",
  "capacity": 30,
  "maxPartySize": 6,
  "enabled": true
}

{
  "revision": 1,
  "startsLocal": "2026-11-12T12:00",
  "endsLocal": "2026-11-12T13:30",
  "capacity": 30,
  "maxPartySize": 6,
  "enabled": false
}

{
  "revision": 2
}

{
  "revision": 1,
  "action": "cancel",
  "reason": "restaurant_closed",
  "comment": "The restaurant will be closed that day."
}

{
  "deploymentId": "11111111-1111-4111-8111-111111111111",
  "slotId": "22222222-2222-4222-8222-222222222222",
  "attemptId": "33333333-3333-4333-8333-333333333333",
  "partySize": 2,
  "phone": "+33123456789",
  "comment": "A high chair if possible.",
  "locale": "en"
}

{
  "confirm": true
}

{
  "reservationToken": "<private-capability>"
}

{
  "reservationToken": "<private-capability>",
  "confirm": true
}

Authentication and browser boundary

The Guest App browser calls its own /api/* backend. That backend authenticates an Innovorder customer, stores the OAuth bearer token in Redis and exposes only a Secure HttpOnly session cookie. Every mutation requires the exact parent origin and an x-csrf-token from GET /api/bootstrap. The Innovorder endpoints serving diners use Authorization: Bearer <customer-token>. Guest App editing requires an administrator or brand backoffice bearer token, with server-side brand ownership checks. Restaurant and brand-group roles are excluded. Application creation and domain/HTTPS operations remain administrator-only. Configuration reads remain public. Their JSON responses use the standard {status, code, message, data} envelope.

Signup, required fields, CAPTCHA, editable email, Stripe recharge and automatic recharge are derived from the published deployment and the live Innovorder brand configuration. The app does not enable unsupported features by hiding a button alone. Supported locales are fr, en, es, de, it, ar, zh-CN, ja, ko and nl; Arabic uses RTL. Dish translations are entered manually, with a fallback to the dish source language when a translation is missing.

Configuration uses a Modules editor for visibility and home ordering. Communications are enabled when the historical configuration omits features.communications; false returns an empty feed without deleting published content. Custom modules are administrator-configured HTTPS destinations, presented in the app as sandboxed iframes. They use a backend-verified SSO proof, never an Innovorder OAuth token. Preview does not load external modules.

{
  "deploymentId": "11111111-1111-4111-8111-111111111111",
  "moduleId": "89bb7181-96b2-45b8-b89a-464414bb3518",
  "restaurantId": 200
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "url": "https://partner.example.org/app",
    "token": "<short-lived-signed-proof>",
    "expiresAt": "2026-09-24T12:01:00Z"
  }
}

Binary PDF. Missing, unrelated or ineligible documents are unavailable; no fallback to another customer or restaurant.

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "deploymentId": "11111111-1111-4111-8111-111111111111",
    "brandId": 100,
    "hostname": "guests.example.test",
    "name": "Example enterprise",
    "version": 1,
    "topUpLimits": {
      "minimumAmount": 100,
      "maximumAmount": 40000
    },
    "configuration": {
      "displayName": "Example restaurant",
      "defaultLocale": "fr",
      "locales": [
        "fr",
        "en"
      ],
      "country": "FR",
      "currency": "EUR",
      "timeZone": "Europe/Paris",
      "restaurants": [
        {
          "restaurantId": 200,
          "name": "Main restaurant"
        }
      ]
    }
  }
}

The configuration example is shortened. Its full contract includes brandHash; logo, icon and hero URLs; primary, accent and background colors; constrained typography, corner radius and card style; module ordering; badge format; feature flags; restaurant ordering/Atlas URLs; and legal/support links. Top-level topUpLimits are read-only values supplied by the API, not theme configuration or browser-selected limits. Administrators and owning brand users can publish and restore deployment versions. Brand writes and restorations preserve technical settings: brand binding, domain, country, currency, time zones, badge format, integration identifiers and custom URLs. Brand users can edit identity, languages, assistance, restaurants and administrator-enabled services; automatic integration links remain server-generated. Publication validates that configured restaurants and currency belong to the dedicated brand.

Restaurant audiences

Each configured restaurant can optionally restrict access with audience: enabled, guestGroupIds and legacyClasses. Omitted or disabled rules allow all application diners. An enabled rule requires at least one selected group. Group IDs must belong to the deployment brand; selecting a parent includes its descendants. Legacy classes match exactly and apply only when the stored student has no structured guestGroupId. Missing, deleted, foreign or ambiguous memberships grant no restricted access. Rules are saved and published with the deployment configuration.

The editor setup returns restaurantAudiences (guestGroups with parentGuestGroupId, and legacyClasses). Published anonymous configuration omits restricted restaurants. Authenticated lists never expose audience rules. Membership is read from the primary database, not from browser data or partner JWT claims. Menus, ratings, Ordering SSO including ticket consumption, Atlas, custom module sessions and new reservations recheck access. Existing personal reservations remain readable and cancellable under their original ownership rules. Atlas provisioning uses separate authenticated server callbacks so its technical restaurant scope does not expose filtered restaurants publicly.

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": [
    {
      "restaurantId": 200,
      "name": "Main restaurant",
      "orderingUrl": "https://ordering.example.test/brand"
    }
  ]
}

Automatic deployment setup

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "brand": {
      "brandId": 100,
      "name": "Example company",
      "brandHash": "example",
      "currency": "EUR",
      "locale": "fr"
    },
    "ordering": {
      "configured": true
    },
    "atlas": {
      "automatic": true,
      "configured": false,
      "status": "pending",
      "embedUrl": "https://atlas.example/embed/guest-footfall"
    },
    "restaurants": [
      {
        "restaurantId": 200,
        "name": "Main restaurant",
        "orderingUrls": {
          "v1": "https://ordering-v1.example/home?brandId=100",
          "v2": "https://ordering-v2.example/example"
        }
      }
    ]
  }
}

Automatic customer domains

Creating an application also initializes durable domain onboarding. An Innovorder administrator copies an A record and the exact Certificate Manager CNAME to the customer's DNS provider. Verification continues without an open browser. A domain becomes ready only after DNS, certificate, certificate-map association and a TLS health check succeed. Content must also be explicitly published; DNS verification never publishes a draft.

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "hostname": "lunch.customer.fr",
    "revision": 1,
    "state": "dns_pending",
    "ready": false,
    "legacy": false,
    "editable": true,
    "published": false,
    "dnsState": "missing",
    "certificateState": "PROVISIONING",
    "checkedAt": null,
    "nextCheckAt": "2026-09-18T12:00:00Z",
    "error": "dns_missing",
    "records": [
      {
        "type": "A",
        "name": "lunch.customer.fr",
        "relativeName": "lunch",
        "value": "34.1.2.3",
        "purpose": "routing"
      },
      {
        "type": "CNAME",
        "name": "_acme-challenge_example.lunch.customer.fr.",
        "relativeName": "_acme-challenge_example.lunch",
        "value": "example.authorize.certificatemanager.goog.",
        "purpose": "certificate"
      }
    ]
  }
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "scheduled": true
  }
}

{
  "hostname": "correct.customer.fr",
  "revision": 1
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "deploymentId": "11111111-1111-4111-8111-111111111111",
    "hostname": "correct.customer.fr",
    "revision": 2
  }
}

States: preparing, dns_pending, certificate_pending, activating, ready; retired applies to replaced domains. Errors distinguish dns_missing, dns_wrong_target, dns_ipv6_conflict, dns_unavailable, certificate_blocked, google_unavailable, https_pending and platform_unavailable. Existing domains retain their current certificate during migration. The public configuration adds domainReady; the Guest BFF does not open new domains while it is false. An application is reachable only when technically activated and published. Domains are checked every minute initially, every fifteen minutes after 24 hours, and hourly after activation. Keep both DNS records for renewal.

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "automatic": true,
    "configured": true,
    "status": "ready"
  }
}

Each configured restaurant may opt in with orderingVersion: 'v1' | 'v2' and atlasAutomatic: true. The API replaces the corresponding URL with its own environment-specific value when saving or publishing. Existing configurations without these properties retain their custom URLs unchanged. Ordering enters the native consumption-mode flow; no sit-in mode is forced. The configured restaurant is bound by the signed Guest SSO context. Atlas tokens remain short-lived and are generated only for an authenticated guest, never persisted in configuration.

The server origin overrides are GUEST_APP_ORDERING_V1_ORIGIN, GUEST_APP_ORDERING_V2_ORIGIN and GUEST_APP_ATLAS_ORIGIN. They accept HTTPS origins only. Atlas is provisioned automatically from the current publication. The setup response reports live partner status; secrets remain encrypted in Atlas. No per-company environment profile is needed. Unpublished drafts never alter the live partner scope.

Templates include sodexo and essentiel version 1, alongside Maison, Pulse, Market and Signature. Sodexo has bundled official brand assets: an empty logoUrl uses its reference logo; a configured HTTPS logo still overrides it. Missing template references still resolve to Maison v1. Publishing and restoring keep the same optimistic revision and tenant checks; no SQL migration is needed.

The Guest-only v1 adapter uses the ordinary OAuth JWT exchange, waits for authenticated identity and verifies server-provided Guest metadata before rendering. It does not invoke the historical balance/email update flow. It strips authentication parameters, preserves the strict parent-message origin/source checks and uses single-use server handoffs for external payment restoration. The legacy engine retains its native language catalog with an English fallback when the requested translation is unavailable; Guest controls and the Essentiel renderer support the ten Guest languages.

Published menus and identified ratings

Weekly menu occurrences are distinct from orderable catalogue products. A publication snapshots the dish content. Dates use the restaurant time zone. A rating opens at the service start and closes at the end of local day J+7. There is one editable integer score per customer and occurrence, no comment and no purchase-proof requirement. A diner receives only their own ratings; Administrators and owning brand users access aggregate counts, score distribution and individual ratings with the guest’s name and customer ID. Names are never exposed to other diners; deleted or out-of-brand customer identities are returned as null. The Guest rating form explains this visibility before submission. Explicit closures are returned as closedServices entries with date and service (lunch or dinner), separately from missing menu data. A service cannot be both closed and populated with dishes; a closure-only week can be published.

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": [
    {
      "menuWeekId": "11111111-1111-4111-8111-111111111111",
      "restaurantId": 200,
      "weekStart": "2026-09-07",
      "title": "Weekly menu",
      "revision": 1,
      "status": "published",
      "publishedVersion": 1,
      "closedServices": [
        {
          "date": "2026-09-07",
          "service": "dinner"
        }
      ],
      "occurrences": [
        {
          "occurrenceId": "22222222-2222-4222-8222-222222222222",
          "dishId": "33333333-3333-4333-8333-333333333333",
          "date": "2026-09-07",
          "service": "lunch",
          "serviceStartTime": "11:30",
          "position": 0,
          "ratingOpensAt": "2026-09-07T09:30:00.000Z",
          "ratingClosesAt": "2026-09-14T21:59:59.999Z",
          "dish": {
            "name": "Vegetable bowl",
            "description": "",
            "category": "main",
            "sourceLocale": "en",
            "allergens": [
              "sesame"
            ],
            "labels": [],
            "nutriScore": "B",
            "translations": {
              "fr": {
                "name": "Assiette de légumes",
                "description": ""
              }
            }
          }
        }
      ]
    }
  ]
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": [
    {
      "occurrenceId": "22222222-2222-4222-8222-222222222222",
      "score": 4,
      "updatedAt": "2026-09-07T12:00:00.000Z"
    }
  ]
}

{
  "score": 4
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "occurrenceId": "22222222-2222-4222-8222-222222222222",
    "score": 4,
    "updatedAt": "2026-09-07T12:00:00.000Z"
  }
}

Published dishes may include labels, allergens and nutriScore. Recognized quality-label identifiers are label-rouge, aoc, aop, igp, agriculture-biologique and bienvenue-a-la-ferme. Standard allergen identifiers are gluten, crustaceans, eggs, fish, peanuts, soy, milk, nuts, celery, mustard, sesame, sulphites, lupin, molluscs. Historical names and custom text remain accepted. Empty or missing allergens mean that information is not provided, not that a dish is allergen-free. The optional Nutri-Score is an operator-supplied uppercase grade A–E; it is never inferred from the recipe or photograph. On update, omission preserves an existing grade, while null clears it. These fields are captured in each published occurrence; saving the dish library does not rewrite an already published menu.

Restaurant menu editor

Menu editing and aggregate reporting allow administrators and owning brand users with backoffice bearer tokens. Brand-group and restaurant roles cannot access these routes, including through direct API calls. Restaurant and brand scope checks remain in place. Draft writes use revisions; a conflicting edit returns 409. Republish corrections retain occurrence IDs and existing ratings, while duplicating a week creates new dated occurrences.

Each occurrence contains dishId, date, service (lunch or dinner), serviceStartTime and position; retain occurrenceId when correcting an existing occurrence. Week starts are Mondays in YYYY-MM-DD format. Omitting closedServices on an edit preserves existing closures; send [] to clear them. Duplicating a week shifts closure dates as well as occurrences.

Scheduled communications

Communications belong to an application and are published independently from its configuration. Administrators and owning brand users can edit them. Saving changes only the draft; the published snapshot remains visible until explicit republication. Every update, publication and withdrawal requires the current revision; stale revisions return 409. Duplication creates a new draft through POST.

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "installed": true
  }
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "items": [],
    "nextCursor": null
  }
}

{
  "content": {
    "title": "Cooking workshop",
    "body": "<p>Meet our <strong>chef</strong>.</p>",
    "sourceLocale": "en",
    "translations": {
      "fr": {
        "title": "Atelier cuisine",
        "body": "<p>Rencontrez notre chef.</p>"
      }
    },
    "audience": "restaurants",
    "restaurantIds": [
      200
    ],
    "startsLocal": "2026-10-01T12:00",
    "endsLocal": "2026-10-01T14:00",
    "timeZone": "Europe/Paris"
  }
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "communicationId": "33333333-3333-4333-8333-333333333333",
    "deploymentId": "11111111-1111-4111-8111-111111111111",
    "revision": 1,
    "status": "draft",
    "published": null
  }
}

{
  "revision": 1,
  "withdrawn": false
}

Title: 160 characters; body: 20,000 UTF-8 bytes after sanitization; optional buttonLabel: 80 characters, required with buttonUrl. Optional imageUrl and buttonUrl accept HTTPS only. Rich text permits paragraphs, bold, italic, lists and links; scripts, styles, embeds and unsafe protocols are removed server-side. Translations use the same text fields. Missing translations fall back to the complete source text with contentLocale identifying its language.

Enter startsLocal and endsLocal as YYYY-MM-DDTHH:mm in the application's IANA timeZone. The server stores UTC startsAt/endsAt and retains the original zone when editing. Nonexistent or ambiguous local times are rejected. Start is inclusive, end exclusive and strictly later than start. Application-wide audience ignores restaurantIds; restaurant targeting requires a nonempty permitted selection.

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "serverNow": "2026-10-01T10:00:00.000Z",
    "nextChangeAt": "2026-10-01T12:00:00.000Z",
    "restaurantScoped": true,
    "items": [
      {
        "communicationId": "33333333-3333-4333-8333-333333333333",
        "title": "Cooking workshop",
        "body": "<p>Meet our chef.</p>",
        "contentLocale": "en",
        "startsAt": "2026-10-01T10:00:00.000Z",
        "endsAt": "2026-10-01T12:00:00.000Z"
      }
    ]
  }
}

All built-in modules and custom modules can be reordered. The optional features.badge and features.balance flags default to enabled for historical configurations. moduleTitles provides optional plain-text display names for built-ins. moduleOrder accepts badge, balance, communications, menus, ratings, ordering, topUp, automaticTopUp, wallet, attendance, registration and custom:<moduleId>. Registration remains on the sign-in screen; ratings require menus. Existing technical capabilities and editor permissions are unchanged.

The home screen shows three active cards, then Show more, in the configured moduleOrder. Badge and balance have no fixed position. restaurantScoped keeps restaurant selection available for active targeted messages. nextChangeAt covers upcoming starts and ends across the application; refresh at this instant using serverNow, every minute while visible, after restaurant changes and on return to the app. No pushes, emails or automatic popups are sent. Preview uses fictitious messages only.

Durable Stripe recharge

Create one UUID per deliberate recharge and retain it through retries. The API stores immutable customer, card, amount, currency and Stripe-account terms before provider calls. It commits the PaymentIntent ID before confirming any charge. Successful receipt verification credits the Innovorder ledger once under a database lock. Polling reconciles the same operation; it does not create a new payment. Automatic reload continues to use the existing customer automatic-reload settings where enabled; CASH and POSTPAYMENT accounts are not eligible. An upstream null automatic-reload configuration means inactive; a configuration object means active, and the Guest BFF normalizes this explicitly.

Combined sales and wallet receipts

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "entries": [
      {
        "key": "sale:123",
        "kind": "sale",
        "occurredAt": "2026-09-16T12:00:00Z",
        "saleAt": "2026-09-15T12:00:00Z",
        "restaurantName": "Main restaurant",
        "timeZone": "Europe/Paris",
        "currency": "EUR",
        "amount": 1000,
        "status": "PAID",
        "number": "T123",
        "walletCount": 1,
        "walletType": null
      }
    ],
    "nextCursor": null
  }
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "key": "wallet:456",
    "kind": "wallet",
    "amount": 2000,
    "currency": "EUR",
    "lines": [],
    "adjustments": [],
    "totals": null,
    "transactions": [
      {
        "id": "456",
        "amount": 2000,
        "currency": "EUR",
        "type": "1",
        "status": "1",
        "occurredAt": "2026-09-16T12:00:00Z",
        "paymentOrigin": "4"
      }
    ]
  }
}

The browser uses /api/history and /api/history/:entryId; the BFF derives tenant and customer from the session. Responses are no-store. The preview uses fictitious data without financial API calls. Failed reads stay distinct from empty history.

{
  "deploymentId": "11111111-1111-4111-8111-111111111111",
  "name": "Personal card",
  "leaseId": "44444444-4444-4444-8444-444444444444",
  "retain": false
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "leaseId": "44444444-4444-4444-8444-444444444444",
    "client_secret": "seti_example_secret_redacted"
  }
}

A successful finalization returns the Card (including cardId) used for recharge. With retain=false, an abandoned temporary card lease is eligible for cleanup after one hour, except while a nonterminal recharge references that card. The same lease protects setup and attachment retries; do not issue a replacement lease after an ambiguous response. retain=true explicitly saves the payment method. The Guest BFF exposes this as POST /api/cards and derives deploymentId from the session hostname. The interface prevents an unmounted card form from starting a recharge.

{
  "operationId": "33333333-3333-4333-8333-333333333333",
  "deploymentId": "11111111-1111-4111-8111-111111111111",
  "cardId": 300,
  "amount": 2000,
  "transient": false
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "operationId": "33333333-3333-4333-8333-333333333333",
    "status": "requires_action",
    "paymentIntentId": "pi_example",
    "clientSecret": "pi_example_secret_redacted"
  }
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "operationId": "33333333-3333-4333-8333-333333333333",
    "status": "succeeded",
    "paymentIntentId": "pi_example",
    "transactionId": 400
  }
}

{}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "operationId": "33333333-3333-4333-8333-333333333333",
    "status": "succeeded",
    "transactionId": 400
  }
}

The browser BFF exposes corresponding /api/topups routes and maps statuses to pending, action and confirmed. Temporary card leases are scoped to this customer; after a terminal payment outcome they are disabled and detached, with durable retry if cleanup fails. Abandoned temporary leases are cleaned after one hour unless an operation is still pending. Provider secrets remain exclusively in the API runtime.

Ordering and Atlas launch sessions

{
  "deploymentId": "11111111-1111-4111-8111-111111111111",
  "restaurantId": 200
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "url": "https://ordering.example.test/?autoLoginJWT=REDACTED&embedded=true",
    "expiresAt": "2026-09-07T10:01:00.000Z"
  }
}

The Guest SSO exchange through /oauth/login also returns data.guestAppContext, containing the verified parentOrigin and restaurantId. Ordering activates its embedded bridge only when those values match the requested context. URL parameters and the referrer alone are never an authorization source. Disabled restaurants keep their historical menus and ratings accessible to authorized diners and Innovorder administrators, but cannot issue a new Ordering session.

{
  "deploymentId": "11111111-1111-4111-8111-111111111111",
  "restaurantId": 200,
  "path": "/payment",
  "cart": {}
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "url": "https://ordering.example.test/payment?autoLoginJWT=REDACTED&guestHandoff=REDACTED",
    "expiresAt": "2026-09-07T10:01:00.000Z",
    "cartExpiresAt": "2026-09-07T10:05:00.000Z"
  }
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "cart": {}
  }
}

The same-origin browser endpoint is POST /api/ordering-handoff with restaurantId, path and cart. The BFF resolves deploymentId from its authenticated context. Never transfer the bearer token through postMessage.

{
  "deploymentId": "11111111-1111-4111-8111-111111111111",
  "restaurantId": 200
}

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "url": "https://atlas.example.test/embed/guest-footfall?locale=fr#token=REDACTED",
    "expiresAt": "2026-09-07T10:15:00.000Z"
  }
}

Atlas shows average ticket counts per 15-minute slot over the previous 28 completed local business dates. All slots use the same observed-day denominator. It is historical information, not live occupancy, unique people or waiting time. An empty history differs from service unavailability. The Guest BFF supplies these launch sessions through /api/ordering-session and /api/atlas-session with a restaurantId; it derives the deployment server-side.

// For Atlas only; keep the short JWT in the fragment and in memory.
window.addEventListener('message', async (event) => {
  if (event.origin !== atlasOrigin || event.source !== iframe.contentWindow) return;
  if (event.data?.type !== 'atlas:token-refresh-needed') return;
  const { url } = await renewGuestAtlasSession(); // same-origin BFF + CSRF
  const token = new URL(url).hash.slice('#token='.length);
  iframe.contentWindow.postMessage({ type: 'atlas:token', token }, atlasOrigin);
});

Apple and Google Wallet

{
  "status": 200,
  "code": "guest_app_succeed",
  "message": "Guest App request succeeded",
  "data": {
    "url": "https://pay.google.com/gp/v/save/REDACTED"
  }
}

These passes identify a badge; they are not NFC payment credentials and do not replace the POS eligibility check. Apple device registration, updates and signed-pass downloads are handled under /guest-app/wallet/apple/v1using the ApplePass protocol. API deployment profiles contain issuer certificates/private keys on the server only. No private credential is returned by configuration or customer endpoints. The API runtime requires the OpenSSL command-line binary to produce the detached CMS signature; verify this prerequisite in the promoted API image.

Errors and activation

Invalid input is 400; expired customer sessions are 401; unauthorized tenant, restaurant or capability is 403; missing resources are 404; revision/payment-term conflicts and closed rating windows are 409; missing provider configuration or upstream failures are 503. Process the machine-readable error code rather than its translated message. Administrative role denials use 401 with the permission_denied code. Apply all three Guest App API migrations (deployment/menu/ratings/wallet, durable recharge, then handoff/card leases), configure approved provider profiles and validate connected sandbox flows before enabling a deployment.