How to build an online shop on Airtable

A shop is products, a cart and a checkout, with the order landing back in Airtable when the money clears. Airtable is genuinely good at two thirds of that — it is a fine catalogue and a fine back office. The difficulty is the middle: the moment a visitor's browser stops browsing and starts asserting things about money.

The browser is a suggestion box

The cart lives in the browser. Everything in it — the items, the quantities, the prices, the discount code, the shipping band — was assembled by code running on a machine you do not control. A visitor can edit any of it before it reaches you. Not through some exotic attack; through the developer tools that ship with every browser.

So the rule that governs the whole build: the browser sends identifiers, never amounts. Your server takes the product IDs and quantities, re-reads the real prices from Airtable, works out the total itself, and charges that. The number the browser thought the order came to is discarded. If your checkout charges what the client-side cart says it should, someone will eventually change a 149 to a 1 and you will ship the goods.

The same applies to everything else a visitor could rewrite. Discount codes are checked against the record, shipping is worked out from the address, and stock is read from the row rather than from whatever the page was showing five minutes ago.

Payment never touches your data layer

Payment goes through a provider — Stripe or similar — and the charge is created by your server, never by the page. The browser gets a token or a hosted checkout session and nothing more. Handling card details yourself also pulls you into PCI obligations you have no reason to take on.

That leads to the thing that kills these builds. An Airtable API key reaches the whole base. There are no per-user permissions, and no way to issue a key that can only append to your orders table. If that key is in your front-end code, it is in the browser, and anyone can read it out of the network tab. A stranger can then write orders, rewrite prices in your product table, and read every customer address you have ever stored.

Writes must go through something that holds the key server-side and decides for itself what to do. A visitor may ask your server to create an order. A visitor may never write to Airtable.

The order is your audit trail

Treat the order table like one. A written row has to say what was actually charged, at the price that applied when it was charged. Prices change. If an order only links to a product and reads the current price back, last month's revenue rewrites itself the next time you run a sale. Store what the customer paid.

Write the order after the payment provider confirms the payment, not when the visitor clicks Pay. And expect the provider to tell you twice — retries and duplicate notifications are normal — so the write path needs a way to recognise an order it has already recorded rather than creating a second one.

Where Airtable runs out

Airtable holds rows, but it is not a transaction store. It has no locking, no atomic decrement, no way to say "reduce this stock count by one, but only if it is still above zero." Two people buying the last unit within the same second will both read 1 remaining and both write 0. You have sold stock you do not have.

The API is also rate limited at roughly five requests per second per base. That is plenty for a shop taking a few orders a day and nowhere near enough for a launch, a newsletter send, or anything that puts a crowd on the page at once.

Airtable still earns its place here. What it cannot hold is the two seconds around a checkout. Low volume, or stock you can oversell and apologise for, and it carries the whole shop comfortably. Scarce inventory, or real concurrency, and the counter needs to live somewhere that can hold a lock, with Airtable behind it doing what it is best at.

One more trap: Airtable attachment URLs expire. Product images pulled straight from the API and cached in your own front end will go dead. Serve them from somewhere built to serve images.

The shape of it

A shop on Airtable works when Airtable is the catalogue and the ledger, and a server you control sits in the middle deciding what things cost and what gets written. Get that division right and the rest is ordinary shop-building. Get it wrong and testing will not tell you. You find out when a stranger pays a pound for something worth a hundred, and when the stock count turns out to have never once been right.