Loading
Agentic commerce platform for merchants
An AI sales floor
for your store.
Sellable staffs your shop with two agents. The Seller quotes from your catalog. The Service Agent looks after orders. Shopping agents from outside connect as guests, and your rules decide which payments go through.
- Policy decides
- deterministic checks
- Consent binds
- single use, expiring
- Webhooks settle
- no UI can mark paid
- Ledger explains
- replay any order
Commerce stackfive planes, one order path
Agents talk at the top. Money moves at the bottom, after policy and consent.
External agents enter through the gatewayYour catalog stays the source of truth
catalog.searchquote.creatednegotiation.counteredpolicy.checkedconsent.issuedorder.createdwebhook.reconciledorder.paid
01
Policy decides
same cart, same verdict, every time
02
Consent binds
amount, payee, and expiry locked
03
Ledger explains
actor, reason, and rule per step
04
Checking rail
razorpay test · signed webhooks
The problem
An AI can find your store. It cannot buy from it.
Chat assistants already recommend products, and newer ones place orders. An order has to clear a chain of gates: stock, price, negotiation limits, spending approval, payment, and proof that it happened. Each gate needs an answer a machine can act on.
A storefront built for clicks answers those questions on a page, for a person. An agent gets no catalog it can read, no quote it can accept, no consent step to pass, and no receipt to check. The purchase stalls right after the first step, and the merchant side never sees it happen.
Merchants see the same gap from the other side. Opening prices, discounts, and payments to a bot with no limits is a risk nobody takes on purpose.
Sellable sits between the two. Agents get a clean way in, and your shop stays in charge.
An agent needs a readable answer at every gate. A storefront built for clicks gives it one and stops.
- 01Find the producta public page, readable today
- 02Check availabilityno live stock feed
- 03Agree on a pricecoupons, not quotes
- 04Negotiate boundslimits never published
- 05Approve the spendno consent step
- 06Pay and prove itno agent payment, no proof
Two agents, one shop
One agent sells. The other looks after orders.
Sellable puts two agents on your staff. The Seller Agent runs the sales floor: discovery, quotes, checkout. The Customer Service Agent handles the order conversation: status, shipping, returns, refunds.
Agents sent by shoppers are guests. They arrive through the gateway, prove who they are, and act only on the permission their customer granted. They never run inside your store.
Seller Agent
The one that sells.
- Reads what the shopper actually wants
- Searches your catalog, nothing else
- Builds quotes your policy allows
- Keeps counter-offers inside your floor and discount cap
- Suggests add-ons you already linked
- Walks the shopper through checkout
It proposes prices and bundles. Policy, consent, and the payment rail decide what goes through.
Customer Service Agent
The one that looks after orders.
- Checks who the customer is first
- Looks up orders inside their permission
- Explains shipping and delivery status
- Opens cases for returns and exchanges
- Files refunds up to the limit you set
- Hands tricky cases to a human, with context
It cannot refund beyond your authority or show one customer another's data. Sensitive cases go to a person.
You
catalog, prices, and rules stay yours
Outside agents
connect as guests, prove who they are
Customers
buy directly or send an agent
A shopper can come in person or send an agent. Both are checked at the gateway; your agents answer from your catalog, and the ledger keeps the receipt.
Merchant control
You set the limits. The agents stay inside them.
The agents handle the back-and-forth with buyers. The numbers that affect margin are yours: what one order may total, how deep a discount can go, which categories are in play, and how many times an agent may counter.
All of it lives in one policy, edited from the console and checked on every cart. An order over your approval line waits until you approve it, and payment stays impossible until you do.
Your catalog is the only source agents can quote from. A product that is not in stock cannot be sold.
Selling rules
PUT /console/policyOrder capthe most one order can total
Item capthe most one item can cost
Discount capthe deepest discount an agent may give
Categorieswhat your agents may sell for you
Negotiationcounter-offers per session
Upsellsadd-ons per session
Approval lineabove it, a person decides
When a rule trips
Below your floorthe counter lands on your floor
Over a capthe cart is denied
Over your lineit waits for your yes
Every edit lands in the ledger as policy.updated
The platform
The machinery behind every sale
Agents do the talking with buyers. Everything that touches money runs through systems that cannot improvise.
01Agent discovery
Your store publishes a manifest, a machine-readable catalog, and ground rules. Agents read them instead of scraping pages.
02Policy engine
Every cart runs the same checks in the same order: floors, caps, budgets, approval limits. No model sits in this path.
03Consent gates
Payment needs a single-use token bound to one order: amount, payee, expiry. Once spent, or once it expires, it is done.
04Ledger
Who acted, what happened, why, and which rule applied. Open any order and replay it line by line.
05Negotiation bounds
The Seller Agent can counter inside your limits. It cannot move the floor, the cap, or the round limit.
The stack
documented
01Public surfacewho you are, what you sell, how to behave
02Gatewayagent keys, signed requests, replay guard
03Catalogyour SKUs, prices, floors, stock
04Seller agentquotes and counters inside your limits
05Policy engineone deterministic pass, three verdicts
06Consentsingle-use, bound to the order
07SettlementRazorpay, signed webhook only
08Ledgerwho, what, why, which rule
Settlement rule
Webhook only
No screen, agent, or admin action can mark an order paid. Only a verified webhook from the payment provider can.
Discovery is public. Ordering is gated. Settlement is verified.
Merchant console
Run the shop from one place
Orders, approvals, rules, and the ledger live in one console. Every number traces back to a real transaction, and every transaction opens up line by line.
ApprovalsOrders over your line wait here. Payment stays impossible until you decide.
OrdersOpen any order down to its ledger lines: quotes, policy checks, consent, payment.
AI SalesTalk to your Seller Agent the way a buyer's agent would, and watch each step land in the ledger.
SupportThe Service Agent answers order questions, opens returns and exchanges, and files refund requests.
Selling RulesOrder caps, discount cap, categories, rounds, and the approval line, edited right here.
Live ActivityThe ledger streaming as events land, filtered by actor or event type.
Sellable console
scoped to your storeHome
Store
Products
Inventory
Orders
Buyers
Sales
AI Sales
Support
AI Storefront
Selling Rules
Approvals
Analyze
Analytics
Live Activity
Evaluations
System
Payments
Operations
Connectors
Developers
Settings
Live activityledger stream
›catalog.searchbuyer agent
›quote.createdseller agent
›policy.checkedpolicy engine · allow
›order.createdcommerce core · awaiting consent
›consent.issuedconsent service · single use
›consent.usedconsent service
›payment.pendingrazorpay · payment link
›order.paidrazorpay · webhook verified
Approvals
RejectApprove
Orders over your approval line wait here. Payment stays impossible until you decide.
Webhooks · signature verifiedConsent · single useKeys · hashed
GET /console/insightsGET /activity/streamGET /console/approvalsGET /console/transactions
Policy and security
The checkpoint before money
Every cart passes the same checks in the same order, and the walk stops at the first failed check. No model runs in this path, so the same cart gets the same verdict, and only a verified webhook can settle a payment.
Policy engine · evaluating
✓
Catalog grounding
the SKU has to exist in your catalog
··
Buyer categories
the cart fits the buyer's permission
··
Merchant categories
the cart fits what you sell
··
Floor price
offers below your floor get countered
··
Buyer budget
the total fits the buyer's ceiling
··
Max order value
a hard cap on every order
··
Approval line
above it, a person decides
EVALUATING…Inside every limit
DETERMINISTIC · NO MODEL IN THIS PATH, the same cart always gets the same verdict.
Groundeda SKU outside your catalog cannot be bought
Boundedfloors, caps, and discounts hold firm
Gatedpast your line, only a person can proceed
Declines come with a code
BELOW_FLOOR_PRICEMAX_DISCOUNT_EXCEEDEDOVER_BUDGETINSUFFICIENT_STOCKMAX_NEGOTIATION_ROUNDSABOVE_APPROVAL_THRESHOLD
Every verdict carries a reason code and a policy reference into the ledger.
Security model
Built for agents spending money
Autonomous buying is a threat model first. Each control below answers one attack, and each one runs in this codebase.
Forged sessions
ES256 + JWKS
Supabase access tokens verify locally against the project's JWKS with strict issuer and audience checks. Keys rotate without a deploy.
sellable/supabase_jwt.py
Cross-merchant access
Per-store scoping
A verified login says nothing about access. Your user id resolves to your store, and another store's id comes back 404.
merchant_users
Database abuse
RLS + zero anon grants
Application tables carry row-level security and zero grants for the anon and authenticated roles. Only the backend's service role touches data.
supabase/migrations
Key leakage and replay
Hashes + nonce claims
Agent keys are stored as SHA-256 hashes. Signed requests carry a timestamp and a nonce that is claimed once and expires after five minutes.
X-SignatureX-Nonce
Forged payment success
Webhook-only settlement
No browser, agent, or admin endpoint can mark an order paid. A signature-verified Razorpay webhook settles it, the amount has to match, and duplicate deliveries are ignored.
POST /webhooks/razorpay
Unbounded agent behavior
Deterministic policy + consent
Floors, caps, thresholds, and catalog grounding are plain code. Payment needs a single-use token bound to one order's amount and payee.
policy.pyconsent.py
Per-IP rate limits on every routePII redacted before the ledgerPrices re-verified before paymentEach control is covered by tests in tests/.
Built for agents
Any agent can find you. You decide who buys.
A shopping agent does not load your storefront. It reads three public files: who you are, what you sell, and how to behave. Any assistant's agent can read them.
To buy, it presents a key or a signed request. You issue, rotate, and revoke those keys from the console — and the gateway rejects anything signed wrong, replayed, or revoked.
Public · no key required
/.well-known/agents.json
FETCHING…How an outside agent buys herethrough your agents · under your policy
Public files in, a signed request at the gateway, quotes and counter-offers inside your bounds, settlement that only a verified webhook closes — and your Service Agent after the sale. The ledger keeps every step.
- Outside agentarrives from the open webno key · no account
- Public fileswho you are · what you sell/.well-known/agents.json
- Gatewaya key or a signed requestX-Agent-Key · X-Signature
- Seller agentquotes, then counter-offersquotes.create · negotiate
- Settlementconsent binds the amountverified webhook marks paid
- Service agentorders, returns, refunds/commerce/support/cases
For developers
One public file makes you findable
Shopping agents start here. Your manifest states who you are and what you support. Everything behind it stays gated until identity, policy, and consent clear.
Public manifest at /.well-known/agents.json
Machine catalog at /catalog.ai.json
Behavior notes at /llms.txt
Settlement only through verified webhooks
zsh — discovery
PUBLIC
$
RUN IT NOW: this endpoint is public and returns your live manifest.
Give your store an AI sales floor.
Put your catalog where agents already shop. You keep the pricing, the approvals, and the final word. The agents do the talking.
Consent-gated Policy-bounded Ledger-audited