Skip to main content
Crave Cloud is the franchise platform behind Crave.js. It gives restaurant brands one integration surface for digital ordering while letting each module be adopted independently, connected to systems the brand already trusts, or kept on the roadmap until the brand is ready. For developers, that means Crave.js is not a standalone demo app. It is the storefront layer inside a broader cloud platform for restaurants with multiple locations, operators, payment accounts, loyalty providers, and guest touchpoints.
This page separates shipped surfaces from target product direction. Named bring-your-own providers are integration boundaries, not guaranteed prebuilt connectors.

​
The platform model

Your world

Guests, teams, apps, kiosks, franchisees, operators, developers, and restaurant locations.

Crave Cloud

Business Manager foundations, Crave.js, API contracts, webhooks, integration health, readiness, and module configuration.

Connected franchise experience

One customer experience across ordering, loyalty, payments, locations, and brand operations as each module is enabled.

​
Ecosystem map

Read Crave Cloud left to right: your guest and operator channels connect once to Crave Cloud, Crave Cloud coordinates the modules, and the brand gets one connected franchise experience. Status labels show what is shipped today versus target direction.
This map is intentionally simplified from the internal architecture diagram. Bring-your-own vendors are integration boundaries, not prebuilt connector promises. Confirm enablement per brand.

​
Core surfaces

​
Choose modules independently

Crave Cloud is designed for gradual adoption. A brand can use Crave.js ordering while keeping an existing loyalty provider, or use the Stripe payment path while connecting an existing ordering platform. The goal is to replace only what needs replacing. For loyalty, Loyalty Interchange Protocol means Crave’s standard contract for balances, rewards, tiers, earning, redemption, refunds, and reversals across channels. The engine and contract exist; the Cloud-to-ordering integration layer is the product glue that makes it usable inside Crave Cloud.
Bring-your-own providers are integration boundaries, not blanket availability promises. Use the current implementation guides and your Crave integration plan to confirm what is enabled for a specific brand.

​
Identity boundary

Crave Cloud keeps guest identity and staff identity separate.
  • Guest identity powers storefront ordering, loyalty, rewards, and customer-facing channels.
  • Staff identity powers Business Manager access, roles, franchise operations, and administrative workflows.
  • Guests never become Business Manager organization members.
  • Crave does not store guest passwords or issue guest auth tokens.
  • Merchant keys and guest JWTs are not sent to Loyalty Interchange Protocol endpoints.
This separation matters for franchise brands because a customer can order across locations without becoming a staff user, and a franchise operator can manage locations without gaining access to guest accounts. The target managed identity path is Clerk-backed Crave Customer Identity. The current storefront implementation still uses Stytch OTP, and bring-your-own identity providers are handled through brand-specific integration planning.

​
Where Crave.js fits

Crave.js is the developer-facing ordering layer inside Crave Cloud:
  • install @craveup/storefront-sdk
  • scaffold storefronts with npx craveup init
  • connect menus, modifiers, carts, checkout, fulfillment, Stripe payments, analytics, and webhooks
  • use typed SDK helpers or direct REST calls
  • customize UI components while keeping the restaurant ordering workflow intact
Crave.js is not the staff dashboard, the loyalty runtime, or a POS replacement. Those belong to other Crave Cloud surfaces or brand-specific integration work. Start with Build a Restaurant Ordering App in Minutes, then use this overview to understand how that storefront fits into Crave Cloud.