How to build a marketplace on Airtable

A marketplace is two products sharing one database. Sellers post listings and manage them; buyers browse, search and enquire. Airtable holds the data for both without complaint. The difficulty is that the same base now has to answer to two different sets of rules, and unlike a portal — where everyone only reads — one of those groups is writing to it.

Two permission shapes, one base

A portal has a single rule. A marketplace has two, and they do not look alike.

A seller may read the public catalogue, and may create and edit listings, but only their own. A buyer may read the public catalogue and write nothing at all, apart from an enquiry.

Airtable can express neither. Its API has no per-user permissions: one key reads and writes every record in the base. Whatever tells a seller from a buyer, and one seller from another, lives in code you write and run somewhere a visitor cannot reach.

Every write goes through a check you control

The mechanism is the one a portal uses, a linked record pointing at the owner, but the check now has to happen in a place people forget.

A read check asks whether the record belongs to the person asking. A write check has to ask the same question before the change is applied, using the record already in the base rather than anything in the request. If a request says "update this listing", and your server fetches that listing, confirms the signed-in seller owns it, and only then writes, you are fine. If your server takes the seller's identity from the request body, you are not: a seller can send someone else's identifier and edit their listings. Identity comes from the session, never from the browser.

The same rule decides whether a listing is public at all. Every listing has a state, and that state is your moderation system: a draft only its owner sees, a published listing everyone sees, a suspended one its owner sees with a reason attached. The failure here is quiet. If the front end sends a status of published and the server writes what it was sent, moderation is decorative, because anyone who can post can publish. The move into published belongs to you or an admin, not to whoever made the request.

Querying is the other half. Public pages must be filtered to published listings on the server. Fetching everything and hiding the rest in the interface protects nothing; the unpublished rows are already in the browser.

Public traffic changes the arithmetic

A portal serves a known, small group. A marketplace serves the open internet, and two Airtable specifics start to matter.

The API allows about five requests per second per base. Thirty clients checking invoices never come close. A listing that gets shared widely does, and when you cross the limit requests start failing for everyone — buyers browsing and sellers posting alike. Public browse pages want to be served from a cache rather than a live call per visitor.

Attachment URLs expire. Listing photos stored in Airtable cannot be baked into a page and left there, or a page built last week shows broken images this week. Photos need somewhere durable to live, or a refresh on the way out.

Enquiries connect two people without exposing either

An enquiry is a record linking a buyer, a listing and its seller, carrying a message. What separates it from a contact form is what it withholds: the buyer never receives the seller's email address, and the seller never receives the buyer's, until the enquiry reaches a state where both have agreed to it.

That means messages travel through you. Your server sends the notification, takes the reply, and passes it on. Neither address appears in any payload sent to a browser, and this is exactly where marketplaces leak. The listing page looks correct because the email is never drawn on screen, but it came down inside the JSON that built the page, and it is sitting in the network tab of every visitor curious enough to look.

Where this leaves you

A marketplace is a portal's ownership rule applied twice: once to decide what a person may see, and again, more strictly, to decide what they may change. Design both in from the beginning. Adding a second audience to a build that assumed one is where the real work, and the real exposure, comes from.