Build with AI

You are a senior full-stack developer. Build a complete, production-ready restaurant ordering website on the Billzova API, using Next.js (App Router) + TypeScript + Tailwind CSS.

First read the complete Billzova API documentation: https://developers.billzova.com/llms-full.txt
(If you cannot open links, ask me to paste it.) Use only endpoints, fields and error codes that appear there.

Rules you must follow (from the Billzova docs — do not invent anything beyond them):
1. API host: https://api.billzova.com — every path below already starts with /v1 (e.g. https://api.billzova.com/v1/menu). Auth header: "Authorization: Bearer <key>". The key is SECRET: read it from an environment variable (BILLZOVA_KEY) on the server only. Never put it in browser code, a mobile app bundle, a URL or git. The browser talks to MY server; my server talks to Billzova.
2. Build and test with a TEST key (bz_test_sk_…). Test orders and bookings never reach the kitchen. Switching to a live key (bz_live_sk_…) must be the only change needed to go live.
3. Send the header "Billzova-Version: 2026-10-17" on every request so behaviour never changes under me.
4. Money is { amount (integer paise), currency, display }. Show the "display" string. Never compute prices, GST, charges or totals myself.
5. Before checkout, price the cart with POST /v1/orders/quote and show exactly its lines, tax, charges and total.
6. Items with sizes have menuItemId: null and a "variants" list — order the chosen variant's menuItemId. Respect each add-on group's min/max. Hide or grey out anything with available: false.
7. Place orders with POST /v1/orders and an "Idempotency-Key" header: one UUID created when the customer taps "Place order", reused on every retry of that same order. Send expectedTotal = the quote's total.amount. On PRICE_CHANGED show the new quote from the error and ask the customer to confirm. On IDEMPOTENCY_IN_PROGRESS wait 2 seconds and retry with the same key.
8. On page load call GET /v1/restaurant. If ordering.acceptingNow is false, disable checkout and show status.label (e.g. "Closed · opens 11:00 AM") or "Not taking orders right now".
9. Payment: pickup → PAY_AT_COUNTER, delivery → CASH_ON_DELIVERY. There is NO online payment yet — do not add a payment gateway step. Delivery needs address (5–300 chars) and a 6-digit pincode; customer phone is a 10-digit Indian mobile.
10. Branch on error.code, never on the message. Show error.message to the customer when it helps (e.g. ITEM_UNAVAILABLE, CLOSED, OUT_OF_AREA, BELOW_MINIMUM). Log error.requestId with every failure.
11. There are no webhooks yet. Show order status by polling GET /v1/orders/{id} every 15 seconds from MY server (stop at COMPLETED, REJECTED or CANCELLED). Statuses: PENDING → ACCEPTED → PREPARING → READY → OUT_FOR_DELIVERY → COMPLETED, or REJECTED (show rejectionReason) / CANCELLED. When OUT_FOR_DELIVERY, show delivery.person name and phone.
12. Cache GET /v1/menu and send its ETag back as If-None-Match (304 = unchanged). Respect rate limits; on 429 wait for Retry-After.
13. Ignore response fields you do not know, and treat unknown enum values gracefully — new ones can be added.

What to build:
- Server-side API client in lib/billzova.ts (fetch wrapper: base URL, auth header, Billzova-Version, JSON errors → typed BillzovaError with code/message/field/requestId, 10 s timeout).
- Route handlers that the browser calls: GET /api/restaurant, GET /api/menu (cached, ETag), POST /api/quote, POST /api/order (creates the Idempotency-Key once per checkout and retries safely), GET /api/order/[id].
- Home page: restaurant name, address, open/closed banner from status.label, menu by category with Veg/Non-veg marks, sizes and add-ons picker.
- Cart (kept in localStorage), quantity controls, item notes ("less spicy").
- Checkout: pickup or delivery (only the types in ordering.types), name, 10-digit phone, delivery address + landmark + pincode (warn early if the pincode is not in ordering.deliveryPincodes when that list is non-empty), minimum order check, live quote with GST lines, "Place order" button that cannot double-submit.
- Order page /order/[id]: status timeline, rejection reason, delivery person, auto-refresh every 15 s.
- Friendly states for every error code the docs list for quote and order.
- .env.example with BILLZOVA_KEY=bz_test_sk_..., README with setup and go-live steps.

Work step by step: show me the file tree first, then each file in full. After the code, give me a test checklist I can run with a test key (one pickup, one delivery, one unavailable item, one price change, a retry of the same order).

You are a senior full-stack developer. Add Billzova online ordering to my EXISTING restaurant website without rebuilding it.

First read the complete Billzova API documentation: https://developers.billzova.com/llms-full.txt
(If you cannot open links, ask me to paste it.) Use only endpoints, fields and error codes that appear there.

Rules you must follow (from the Billzova docs — do not invent anything beyond them):
1. API host: https://api.billzova.com — every path below already starts with /v1 (e.g. https://api.billzova.com/v1/menu). Auth header: "Authorization: Bearer <key>". The key is SECRET: read it from an environment variable (BILLZOVA_KEY) on the server only. Never put it in browser code, a mobile app bundle, a URL or git. The browser talks to MY server; my server talks to Billzova.
2. Build and test with a TEST key (bz_test_sk_…). Test orders and bookings never reach the kitchen. Switching to a live key (bz_live_sk_…) must be the only change needed to go live.
3. Send the header "Billzova-Version: 2026-10-17" on every request so behaviour never changes under me.
4. Money is { amount (integer paise), currency, display }. Show the "display" string. Never compute prices, GST, charges or totals myself.
5. Before checkout, price the cart with POST /v1/orders/quote and show exactly its lines, tax, charges and total.
6. Items with sizes have menuItemId: null and a "variants" list — order the chosen variant's menuItemId. Respect each add-on group's min/max. Hide or grey out anything with available: false.
7. Place orders with POST /v1/orders and an "Idempotency-Key" header: one UUID created when the customer taps "Place order", reused on every retry of that same order. Send expectedTotal = the quote's total.amount. On PRICE_CHANGED show the new quote from the error and ask the customer to confirm. On IDEMPOTENCY_IN_PROGRESS wait 2 seconds and retry with the same key.
8. On page load call GET /v1/restaurant. If ordering.acceptingNow is false, disable checkout and show status.label (e.g. "Closed · opens 11:00 AM") or "Not taking orders right now".
9. Payment: pickup → PAY_AT_COUNTER, delivery → CASH_ON_DELIVERY. There is NO online payment yet — do not add a payment gateway step. Delivery needs address (5–300 chars) and a 6-digit pincode; customer phone is a 10-digit Indian mobile.
10. Branch on error.code, never on the message. Show error.message to the customer when it helps (e.g. ITEM_UNAVAILABLE, CLOSED, OUT_OF_AREA, BELOW_MINIMUM). Log error.requestId with every failure.
11. There are no webhooks yet. Show order status by polling GET /v1/orders/{id} every 15 seconds from MY server (stop at COMPLETED, REJECTED or CANCELLED). Statuses: PENDING → ACCEPTED → PREPARING → READY → OUT_FOR_DELIVERY → COMPLETED, or REJECTED (show rejectionReason) / CANCELLED. When OUT_FOR_DELIVERY, show delivery.person name and phone.
12. Cache GET /v1/menu and send its ETag back as If-None-Match (304 = unchanged). Respect rate limits; on 429 wait for Retry-After.
13. Ignore response fields you do not know, and treat unknown enum values gracefully — new ones can be added.

My stack: [WRITE YOUR STACK HERE — e.g. WordPress on shared hosting / Laravel / static HTML + Node / Django].

What to build:
- The smallest possible server-side piece for my stack (e.g. a WordPress plugin with REST routes, a PHP file, an Express router) that proxies: restaurant, menu, quote, order, order status — adding the key and headers server-side.
- A drop-in ordering widget (vanilla JS + CSS, no framework unless my stack already has one) I can place on my menu page: menu with sizes/add-ons, cart, checkout form, quote, place order, status view.
- Match my site's look: ask me for my brand colours and font, or read them from the CSS I paste.
- Clear install steps for my hosting, where to put BILLZOVA_KEY, and how to switch to the live key.

Ask me any question you need about my stack before writing code.

You are a senior full-stack developer. Build a table-booking flow on the Billzova API for my restaurant website (use my existing stack; default to Next.js + TypeScript if I do not say).

First read the complete Billzova API documentation: https://developers.billzova.com/llms-full.txt
(If you cannot open links, ask me to paste it.) Use only endpoints, fields and error codes that appear there.

Rules you must follow (from the Billzova docs — do not invent anything beyond them):
1. API host: https://api.billzova.com — every path below already starts with /v1 (e.g. https://api.billzova.com/v1/menu). Auth header: "Authorization: Bearer <key>". The key is SECRET: read it from an environment variable (BILLZOVA_KEY) on the server only. Never put it in browser code, a mobile app bundle, a URL or git. The browser talks to MY server; my server talks to Billzova.
2. Build and test with a TEST key (bz_test_sk_…). Test orders and bookings never reach the kitchen. Switching to a live key (bz_live_sk_…) must be the only change needed to go live.
3. Send the header "Billzova-Version: 2026-10-17" on every request so behaviour never changes under me.
4. Money is { amount (integer paise), currency, display }. Show the "display" string. Never compute prices, GST, charges or totals myself.
5. Before checkout, price the cart with POST /v1/orders/quote and show exactly its lines, tax, charges and total.
6. Items with sizes have menuItemId: null and a "variants" list — order the chosen variant's menuItemId. Respect each add-on group's min/max. Hide or grey out anything with available: false.
7. Place orders with POST /v1/orders and an "Idempotency-Key" header: one UUID created when the customer taps "Place order", reused on every retry of that same order. Send expectedTotal = the quote's total.amount. On PRICE_CHANGED show the new quote from the error and ask the customer to confirm. On IDEMPOTENCY_IN_PROGRESS wait 2 seconds and retry with the same key.
8. On page load call GET /v1/restaurant. If ordering.acceptingNow is false, disable checkout and show status.label (e.g. "Closed · opens 11:00 AM") or "Not taking orders right now".
9. Payment: pickup → PAY_AT_COUNTER, delivery → CASH_ON_DELIVERY. There is NO online payment yet — do not add a payment gateway step. Delivery needs address (5–300 chars) and a 6-digit pincode; customer phone is a 10-digit Indian mobile.
10. Branch on error.code, never on the message. Show error.message to the customer when it helps (e.g. ITEM_UNAVAILABLE, CLOSED, OUT_OF_AREA, BELOW_MINIMUM). Log error.requestId with every failure.
11. There are no webhooks yet. Show order status by polling GET /v1/orders/{id} every 15 seconds from MY server (stop at COMPLETED, REJECTED or CANCELLED). Statuses: PENDING → ACCEPTED → PREPARING → READY → OUT_FOR_DELIVERY → COMPLETED, or REJECTED (show rejectionReason) / CANCELLED. When OUT_FOR_DELIVERY, show delivery.person name and phone.
12. Cache GET /v1/menu and send its ETag back as If-None-Match (304 = unchanged). Respect rate limits; on 429 wait for Retry-After.
13. Ignore response fields you do not know, and treat unknown enum values gracefully — new ones can be added.

Extra rules for bookings:
- Read booking settings from GET /v1/restaurant (booking.enabled, booking.maxPeople, booking.daysAhead, booking.price). Hide the feature if booking.enabled is false; above maxPeople, show "Please call the restaurant" with the restaurant phone.
- Free times come ONLY from GET /v1/reservations/availability?date=YYYY-MM-DD&people=N. Never invent slots. Dates are restaurant-local (Asia/Kolkata).
- Book with POST /v1/reservations and an Idempotency-Key (date, time, people, customer {name, phone, email?}, occasion, notes).
- A new booking is PENDING until the restaurant confirms it. Show that clearly, and poll GET /v1/reservations/{id} every 30 s to show Confirmed / Declined (with the reason).
- If booking.price is set, show it. Paying online is NOT available yet — say "pay at the restaurant".
- Let the customer cancel with POST /v1/reservations/{id}/cancel and show the CANNOT_CANCEL message if it is past the cut-off.

Deliver: booking page UI (mobile first), server routes, confirmation page, and a test checklist with a test key.

You are a senior full-stack developer. Build a customer-facing order status page on my website for orders placed through the Billzova API.

First read the complete Billzova API documentation: https://developers.billzova.com/llms-full.txt
(If you cannot open links, ask me to paste it.) Use only endpoints, fields and error codes that appear there.

Rules you must follow (from the Billzova docs — do not invent anything beyond them):
1. API host: https://api.billzova.com — every path below already starts with /v1 (e.g. https://api.billzova.com/v1/menu). Auth header: "Authorization: Bearer <key>". The key is SECRET: read it from an environment variable (BILLZOVA_KEY) on the server only. Never put it in browser code, a mobile app bundle, a URL or git. The browser talks to MY server; my server talks to Billzova.
2. Build and test with a TEST key (bz_test_sk_…). Test orders and bookings never reach the kitchen. Switching to a live key (bz_live_sk_…) must be the only change needed to go live.
3. Send the header "Billzova-Version: 2026-10-17" on every request so behaviour never changes under me.
4. Money is { amount (integer paise), currency, display }. Show the "display" string. Never compute prices, GST, charges or totals myself.
5. Before checkout, price the cart with POST /v1/orders/quote and show exactly its lines, tax, charges and total.
6. Items with sizes have menuItemId: null and a "variants" list — order the chosen variant's menuItemId. Respect each add-on group's min/max. Hide or grey out anything with available: false.
7. Place orders with POST /v1/orders and an "Idempotency-Key" header: one UUID created when the customer taps "Place order", reused on every retry of that same order. Send expectedTotal = the quote's total.amount. On PRICE_CHANGED show the new quote from the error and ask the customer to confirm. On IDEMPOTENCY_IN_PROGRESS wait 2 seconds and retry with the same key.
8. On page load call GET /v1/restaurant. If ordering.acceptingNow is false, disable checkout and show status.label (e.g. "Closed · opens 11:00 AM") or "Not taking orders right now".
9. Payment: pickup → PAY_AT_COUNTER, delivery → CASH_ON_DELIVERY. There is NO online payment yet — do not add a payment gateway step. Delivery needs address (5–300 chars) and a 6-digit pincode; customer phone is a 10-digit Indian mobile.
10. Branch on error.code, never on the message. Show error.message to the customer when it helps (e.g. ITEM_UNAVAILABLE, CLOSED, OUT_OF_AREA, BELOW_MINIMUM). Log error.requestId with every failure.
11. There are no webhooks yet. Show order status by polling GET /v1/orders/{id} every 15 seconds from MY server (stop at COMPLETED, REJECTED or CANCELLED). Statuses: PENDING → ACCEPTED → PREPARING → READY → OUT_FOR_DELIVERY → COMPLETED, or REJECTED (show rejectionReason) / CANCELLED. When OUT_FOR_DELIVERY, show delivery.person name and phone.
12. Cache GET /v1/menu and send its ETag back as If-None-Match (304 = unchanged). Respect rate limits; on 429 wait for Retry-After.
13. Ignore response fields you do not know, and treat unknown enum values gracefully — new ones can be added.

- Route /order/[id] on my site. My server calls GET /v1/orders/{id} with the key (orders:read) and returns only what the customer needs.
- Show order number, items, total (display strings), a timeline (placed → accepted → preparing → ready → out for delivery → completed), the rejection reason if REJECTED, and the delivery person's name + call button when OUT_FOR_DELIVERY.
- Refresh every 15 s while the order is active; stop at COMPLETED, REJECTED or CANCELLED.
- Allow "Cancel order" only while PENDING (POST /v1/orders/{id}/cancel), with a reason.
- Do not rely on the trackingUrl field — build the page from GET /v1/orders/{id}.

You are a senior full-stack developer. Show the restaurant's live Billzova menu on my website — display only, no ordering yet.

First read the complete Billzova API documentation: https://developers.billzova.com/llms-full.txt
(If you cannot open links, ask me to paste it.) Use only endpoints, fields and error codes that appear there.

Rules you must follow (from the Billzova docs — do not invent anything beyond them):
1. API host: https://api.billzova.com — every path below already starts with /v1 (e.g. https://api.billzova.com/v1/menu). Auth header: "Authorization: Bearer <key>". The key is SECRET: read it from an environment variable (BILLZOVA_KEY) on the server only. Never put it in browser code, a mobile app bundle, a URL or git. The browser talks to MY server; my server talks to Billzova.
2. Build and test with a TEST key (bz_test_sk_…). Test orders and bookings never reach the kitchen. Switching to a live key (bz_live_sk_…) must be the only change needed to go live.
3. Send the header "Billzova-Version: 2026-10-17" on every request so behaviour never changes under me.
4. Money is { amount (integer paise), currency, display }. Show the "display" string. Never compute prices, GST, charges or totals myself.
5. Before checkout, price the cart with POST /v1/orders/quote and show exactly its lines, tax, charges and total.
6. Items with sizes have menuItemId: null and a "variants" list — order the chosen variant's menuItemId. Respect each add-on group's min/max. Hide or grey out anything with available: false.
7. Place orders with POST /v1/orders and an "Idempotency-Key" header: one UUID created when the customer taps "Place order", reused on every retry of that same order. Send expectedTotal = the quote's total.amount. On PRICE_CHANGED show the new quote from the error and ask the customer to confirm. On IDEMPOTENCY_IN_PROGRESS wait 2 seconds and retry with the same key.
8. On page load call GET /v1/restaurant. If ordering.acceptingNow is false, disable checkout and show status.label (e.g. "Closed · opens 11:00 AM") or "Not taking orders right now".
9. Payment: pickup → PAY_AT_COUNTER, delivery → CASH_ON_DELIVERY. There is NO online payment yet — do not add a payment gateway step. Delivery needs address (5–300 chars) and a 6-digit pincode; customer phone is a 10-digit Indian mobile.
10. Branch on error.code, never on the message. Show error.message to the customer when it helps (e.g. ITEM_UNAVAILABLE, CLOSED, OUT_OF_AREA, BELOW_MINIMUM). Log error.requestId with every failure.
11. There are no webhooks yet. Show order status by polling GET /v1/orders/{id} every 15 seconds from MY server (stop at COMPLETED, REJECTED or CANCELLED). Statuses: PENDING → ACCEPTED → PREPARING → READY → OUT_FOR_DELIVERY → COMPLETED, or REJECTED (show rejectionReason) / CANCELLED. When OUT_FOR_DELIVERY, show delivery.person name and phone.
12. Cache GET /v1/menu and send its ETag back as If-None-Match (304 = unchanged). Respect rate limits; on 429 wait for Retry-After.
13. Ignore response fields you do not know, and treat unknown enum values gracefully — new ones can be added.

- Fetch GET /v1/menu on my server and cache it; refresh with If-None-Match / ETag every 5 minutes (304 = unchanged).
- Render categories in sortOrder, items with name, description, Veg/Non-veg/Egg mark from foodType, price display (or every size with its price), and mark available: false items as "Sold out".
- Add schema.org Menu / MenuItem JSON-LD for SEO.
- Use a key with only the menu:read and restaurant:read scopes, and show the open/closed label from GET /v1/restaurant.
- Make it easy to add ordering later (keep the data layer separate).

You are a senior full-stack developer. Review my Billzova API integration before it goes live. I will paste my code below.

First read the complete Billzova API documentation: https://developers.billzova.com/llms-full.txt
(If you cannot open links, ask me to paste it.) Use only endpoints, fields and error codes that appear there.

Rules you must follow (from the Billzova docs — do not invent anything beyond them):
1. API host: https://api.billzova.com — every path below already starts with /v1 (e.g. https://api.billzova.com/v1/menu). Auth header: "Authorization: Bearer <key>". The key is SECRET: read it from an environment variable (BILLZOVA_KEY) on the server only. Never put it in browser code, a mobile app bundle, a URL or git. The browser talks to MY server; my server talks to Billzova.
2. Build and test with a TEST key (bz_test_sk_…). Test orders and bookings never reach the kitchen. Switching to a live key (bz_live_sk_…) must be the only change needed to go live.
3. Send the header "Billzova-Version: 2026-10-17" on every request so behaviour never changes under me.
4. Money is { amount (integer paise), currency, display }. Show the "display" string. Never compute prices, GST, charges or totals myself.
5. Before checkout, price the cart with POST /v1/orders/quote and show exactly its lines, tax, charges and total.
6. Items with sizes have menuItemId: null and a "variants" list — order the chosen variant's menuItemId. Respect each add-on group's min/max. Hide or grey out anything with available: false.
7. Place orders with POST /v1/orders and an "Idempotency-Key" header: one UUID created when the customer taps "Place order", reused on every retry of that same order. Send expectedTotal = the quote's total.amount. On PRICE_CHANGED show the new quote from the error and ask the customer to confirm. On IDEMPOTENCY_IN_PROGRESS wait 2 seconds and retry with the same key.
8. On page load call GET /v1/restaurant. If ordering.acceptingNow is false, disable checkout and show status.label (e.g. "Closed · opens 11:00 AM") or "Not taking orders right now".
9. Payment: pickup → PAY_AT_COUNTER, delivery → CASH_ON_DELIVERY. There is NO online payment yet — do not add a payment gateway step. Delivery needs address (5–300 chars) and a 6-digit pincode; customer phone is a 10-digit Indian mobile.
10. Branch on error.code, never on the message. Show error.message to the customer when it helps (e.g. ITEM_UNAVAILABLE, CLOSED, OUT_OF_AREA, BELOW_MINIMUM). Log error.requestId with every failure.
11. There are no webhooks yet. Show order status by polling GET /v1/orders/{id} every 15 seconds from MY server (stop at COMPLETED, REJECTED or CANCELLED). Statuses: PENDING → ACCEPTED → PREPARING → READY → OUT_FOR_DELIVERY → COMPLETED, or REJECTED (show rejectionReason) / CANCELLED. When OUT_FOR_DELIVERY, show delivery.person name and phone.
12. Cache GET /v1/menu and send its ETag back as If-None-Match (304 = unchanged). Respect rate limits; on 429 wait for Retry-After.
13. Ignore response fields you do not know, and treat unknown enum values gracefully — new ones can be added.

Check every point above and also:
- Is the secret key ever reachable from the browser, a mobile bundle, logs or git?
- Can a slow network or double tap create two orders? (Idempotency-Key created once per checkout and reused on retry?)
- Are totals always the quote's, never calculated locally? Is expectedTotal sent and PRICE_CHANGED handled?
- Are CLOSED, NOT_ACCEPTING, OUT_OF_AREA, BELOW_MINIMUM, ITEM_UNAVAILABLE, RATE_LIMITED and 5xx handled with clear customer messages?
- Is the Billzova-Version header sent? Are unknown fields and enum values tolerated?
- Is order status polled at a sensible rate and stopped at final states?
- Is anything assuming online payment or webhooks (neither exists yet)?

Answer with: 1) blocking problems, 2) should-fix, 3) nice-to-have — each with the exact file/line and the corrected code.

My code:
[PASTE YOUR CODE HERE]

You are helping me debug a Billzova API call. First read the docs: https://developers.billzova.com/llms-full.txt

Here is what I sent and what came back:
- Endpoint and method: [e.g. POST /v1/orders]
- Headers (REMOVE the key — show only its first 12 characters, e.g. bz_test_sk_ab…): [ ]
- Request body: [ ]
- Response status and body (includes error.code, error.message, error.requestId): [ ]

Explain the cause using the error code table in the docs, show the corrected request, and tell me how my code should handle this code in future. If it looks like a problem on Billzova's side, tell me to contact support with the requestId (info@billzova.com or WhatsApp +91-8869997605).