> ## Documentation Index
> Fetch the complete documentation index at: /docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Prebuilt Storefront Prompt

> Give an AI coding agent the direct public Storefront API security and delivery contract.

First complete [agent setup](/docs/ai-onboarding.md) and confirm the supported SDK/API
pair for your restaurant. Then give your coding agent the implementation brief
below.

```text theme={null}
Read https://developer.craveup.com/agents.md first. Confirm that this target API supports
the published 2.0.1 SDK contract below; if compatibility is not established, stop and report
the missing supported release pair instead of adapting or guessing a transport.

Build a release-quality Crave restaurant storefront while keeping checkout visibly unavailable
until Crave's Stripe direct-charge activation lock is removed.

Use the exact @craveup/storefront-sdk@2.0.1 package with:
const crave = createStorefrontClient({
  baseUrl: process.env.NEXT_PUBLIC_CRAVEUP_API_URL!,
  sessionStore,
  getAuthToken,
  getMerchantSlug: () => merchantSlug,
});

Requirements:
- Published catalog reads are anonymous; never add a browser API key.
- Use versioned sessionStorage scoped by canonical API environment, merchant, and location for cart capability and revision state.
- Keep cart capabilities, customer JWTs, receipt tokens, and PaymentIntent client secrets out of URLs, logs, analytics, and persistent storage.
- Start ordering sessions with idempotency, then use SDK cart methods so capability, ETag, If-Match, and idempotency headers remain consistent.
- On CART_CONFLICT, reload current cart state before presenting a retry.
- Use the environment-specific Customer Clerk application for sign-in, recovery, logout, and token refresh. Crave exposes no customer login or OTP endpoints.
- For signed-in customer calls, obtain a short-lived crave-customer JWT from the active Clerk session through getAuthToken, provide getMerchantSlug separately, and never persist the JWT yourself.
- Prepare the documented Stripe.js confirmation and all four order-result states for the future
  activated contract, but do not claim or simulate successful payment admission today.
- If checkout returns STRIPE_DIRECT_CHARGE_CUTOVER_INCOMPLETE, show a temporarily unavailable state;
  do not retry, bypass, or fall back to a different processor.
- Capture receipt capabilities from URL fragments, remove the fragment immediately, and keep each capability only in tab-scoped storage scoped by API environment, merchant, and receipt ID.
- Keep Stripe secret keys, POS credentials, loyalty credentials, webhook secrets, and private Crave integration keys on the API service.
- Use exact CORS origins for each deployed storefront.

Before completion, run tests, lint, type checking, a production build, a browser-bundle credential
scan, and sandbox menu/cart checks that assert the checkout lock. Report exact commands and remaining
deployment requirements; do not report an end-to-end paid order until activation evidence exists.
```

Useful references:

* [Storefront SDK](/docs/getting-started/storefront-sdk.md)
* [API overview](/docs/api-reference/overview/api-overview.md)
* [Build a Custom Storefront](/docs/guides/build-custom-storefront.md)
* [Deployment](/docs/guides/deployment.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.