Kuber documentation

Creating a site scaffolds its pages, sections and per-section writing prompts from an industry plan, with the four legally required pages appended automatically.

Needs: an LLM key to draft the actual copy — the structure is created either way, deliberately empty until then

Every write is claim-guarded — copy that reads as a specific factual claim is held for review until an attributed owner confirms it. Every content change now snapshots a pre-image before it lands, so an accidental deletion has an undo. Media upload is a presigned direct-to-bucket PUT/GET — bytes never transit this server — but no server-side resize or compression runs, so images serve at upload size.

Needs: object storage credentials for media upload and the version history's asset storage

Header and footer ordering, and a page is hidden rather than deleted by default. A required legal page cannot be deleted at all; any page on a published site needs an approval first.

Breakpoint overrides apply on the way out and are never written back, so hiding a banner on mobile leaves desktop untouched.

The two cannot drift because they share the auditor. No score and no ranking claim is returned — only findings. POST .../sitemap can now actually submit the generated sitemap through Khoji's own Google Search Console OAuth connection — the same connection, since Search Console is a property of the domain, not of which agent asks — rather than a second one.

Needs: a Google Search Console connection (via Khoji's OAuth flow) for actual sitemap submission — audit, meta editing and generating the XML need no credential

A publish re-runs the readiness gate, renders every page and records a deployment. It lands pending-host — explicitly not public.

Needs: a hosting or CDN target credential to actually upload the rendered site

Produces the A, CNAME and TXT records to add at your own registrar, with an explicit do-not-touch-MX warning. Kuber holds no registrar credential and writes no DNS itself.

Needs: a resolver for propagation checking and an ACME account for TLS — activation itself is approval-gated already

Single-product create/update joins the existing bulk import, all against the same shared catalogue Wavy uses. Variants now have their own table: a size or colour with its own stock quantity, reserved atomically at order time with a conditional UPDATE so two simultaneous checkouts for the last unit cannot both succeed. No third-party credential anywhere in this capability.

Value floor and ceiling, pincode allow and block lists and optional phone verification, evaluated at checkout with a reason. Now that an orders table exists, POST .../mark-collected moves a cod_pending order to cod_collected and stamps when, refusing a second mark on an already-settled order. Cash on delivery needs no third-party credential by definition.

Stores only a provider name and a public merchant reference; anything shaped like a card number, CVV or VPA is refused before the approval is even read.

Needs: the gateway's own key and webhook secret to actually take payment — this schema cannot hold either

State code and a real check-digit algorithm validated locally; CGST/SGST or IGST computed so the halves always sum to the tax charged. GET .../invoice now generates a numbered tax invoice once per order, idempotently, reading each line's HSN/rate from the product's current listing and refusing outright if any is undeclared rather than guessing a rate. The invoice number is spent from the seller's own counter with a conditional-UPDATE-then-retry technique, so two orders invoicing at once cannot collide.

Needs: a GSP (GST Suvidha Provider) account — GST_IRP_GSP_CLIENT_ID, GST_IRP_GSP_CLIENT_SECRET, GST_IRP_GSTIN_USERNAME, GST_IRP_GSTIN_PASSWORD — only for e-invoice IRP registration; quoting and generating the invoice itself need none

Percentage and flat codes with minimums, caps, windows and per-customer limits. The redemption limit is a conditional UPDATE that tests and increments in one statement.

Honeypot plus timing and link heuristics; a submission flagged as spam is filed, not silently discarded. A form can now name a notify_email, and a clean submission is emailed to it through the platform's own sender — the response says exactly what happened (sent, no address set, filed as spam, or a named failure), and a failed or skipped send never blocks recording the lead itself.

Needs: ZeptoMail credentials for owner email notification, and a hosted site (store-hosting-cdn) for the public embed endpoint an unauthenticated visitor's browser would call — recording the lead itself needs neither

Cart, checkout quote and order all run against the site's own catalogue: prices are re-read on every step, never trusted from the client, and a checkout session freezes the coupon quote, GST split and COD eligibility it computed so the order records exactly what a shopper agreed to. Stock is reserved with one conditional UPDATE per tracked variant, and order creation is idempotent per checkout session so a mobile retry cannot double-charge inventory. A COD checkout is genuinely complete end to end with no credential.

Needs: a connected payment gateway (see upi-payment-collection) for payment_method=gateway — refused with a 409 otherwise; COD needs nothing

Status moves through a fixed line so the tracking page can trust what it says rather than jumping anywhere from anywhere; cancelling requires a reason and restocks every tracked variant. Shipment create/update and tracking history are real and complete — every event is written by the seller, and the customer is emailed on shipped/out-for-delivery/delivered when they left an address, never blocking the update if the send fails. No courier is chosen and no courier API is called anywhere — every tracking event is manual, never fetched.

Needs: a decision on which courier partner(s) to integrate and that partner's API credential — none exists today, so this is a code gap, not only a missing key

Staff hours, slot listing, booking, reschedule and cancel all run locally end to end. Double-booking is refused by a UNIQUE database constraint rather than a read-then-write, so two simultaneous requests for one slot always resolve to exactly one appointment. An email reminder sends through the platform's sender when the customer left an email; a WhatsApp reminder is always recorded skipped. Google Calendar sync has no code path at all on this deployment, not merely an unset credential.

Needs: ZeptoMail credentials for email reminders (booking itself needs none); a connected WhatsApp number and Google Calendar OAuth are not built at all yet

A share link to the site's own product-grid page is real end to end against Kuber's own data — slug, click count, first and last click — with no Meta credential involved. Connecting a channel is recorded and stays pending_credentials; every sync attempt writes a log row rather than failing silently. No route promises a push that cannot happen.

Needs: the WhatsApp Business API or the Meta Commerce/Instagram Shopping API for a native catalogue push — the share link itself needs neither

Matching the specification's own integration note (none required): page views and cart-funnel events are Kuber's own rows, and overview aggregates traffic, checkout starts and completed-order revenue over a window. Revenue is grouped by currency and never summed across one. Export returns CSV or JSON inline in the response body — nothing is written to local disk. No third-party analytics script runs on a Kuber page.

Scaffold a site from an industry plan — copy left empty, not invented (HTTP 201). Four more pages — privacy, terms, refund and contact — are appended in the same call and are not shown here for brevity. None of them can be deleted afterward.

{
  "name": "Kaveri Spices",
  "industry": "restaurants",
  "language": "en",
  "sells_online": true,
  "brief": "Home-style Andhra meals, tiffin service."
}

{
  "id": "site-1",
  "name": "Kaveri Spices",
  "industry": "restaurants",
  "sells_online": true,
  "pages": [
    {
      "id": "pg-1",
      "kind": "home",
      "slug": "",
      "sections": [
        {
          "id": "sec-1",
          "heading": "",
          "body": "",
          "prompt": "What this section needs: a one-line opening statement about the kitchen."
        }
      ]
    }
  ]
}

A specific claim in the copy is held for review, not published silently (HTTP 200). The owner then calls POST .../sections/{id}/confirm with a note ("we do offer this") to clear the hold. Confirming a section with nothing held returns 409: 'Nothing is being held on this section.'

{
  "body": "Free delivery across the city."
}

{
  "id": "sec-1",
  "body": "Free delivery across the city.",
  "review_state": "held",
  "review_findings": [
    "'Free delivery across the city' is a specific service claim."
  ]
}

Request an itemised approval, then grant it (HTTP 201). Deciding it — POST .../approvals/appr-1/decide {"decision":"granted"} — returns the same object with decision: "granted" and decided_by set.

{
  "action": "publish_site",
  "payload": {}
}

{
  "id": "appr-1",
  "action": "publish_site",
  "decision": "pending",
  "manifest": {
    "pages": [
      "home",
      "menu",
      "contact"
    ],
    "domain": null
  },
  "expires_at": "2026-08-17T10:00:00Z"
}

Publish succeeds against an approval whose digest still matches (HTTP 201). status is always pending_host here — never live. Uploading to a real host or CDN needs a separate credential.

{
  "approval_id": "appr-2"
}

{
  "id": "dep-1",
  "site_id": "site-1",
  "status": "pending_host",
  "content_digest": "3f9a...",
  "log": [
    "readiness gate passed",
    "rendered 5 pages"
  ]
}

Publish refused: the site changed after the approval was granted (HTTP 409). This is the approve-edit-publish sequence the refusal above describes, made concrete: edit any section after the grant and this is what publish returns instead of a deployment.

{
  "approval_id": "appr-1"
}

{
  "code": "approval-stale",
  "message": "The site changed after this was approved, so the approval no longer describes what would go live. Review the changes and ask for approval again."
}

A repeated order reference replays the original discount, never a second one (HTTP 201). INR 120.00 off a INR 1,200.00 order. Retrying with the same order_ref returns replayed: true and the identical discount_minor — a conditional UPDATE (WHERE redeemed_count < max_redemptions) plus a unique constraint on (coupon_id, order_ref) makes an oversell or a double redemption structurally impossible.

{
  "order_ref": "ORD-1042",
  "order_total_minor": 120000,
  "currency": "INR",
  "customer_ref": "cust-9"
}

{
  "code": "DIWALI10",
  "discount_minor": 12000,
  "currency": "INR",
  "order_ref": "ORD-1042",
  "replayed": false
}

Tax split computed so the halves always sum to the tax charged (HTTP 200). INR 100.00 taxable at 5% intra-state splits into INR 2.50 CGST plus INR 2.50 SGST — a quote, priced before checkout. Once an order exists, GET .../orders/{order_id}/invoice generates a numbered tax invoice against it idempotently, one per order.

{
  "place_of_supply": "27",
  "currency": "INR",
  "lines": [
    {
      "description": "Tiffin box",
      "hsn": "2106",
      "rate": 5,
      "taxable_minor": 10000
    }
  ]
}

{
  "intra_state": true,
  "currency": "INR",
  "lines": [
    {
      "taxable_minor": 10000,
      "cgst_minor": 250,
      "sgst_minor": 250,
      "igst_minor": 0,
      "total_minor": 10500
    }
  ],
  "taxable_minor": 10000,
  "tax_minor": 500,
  "total_minor": 10500
}