# API keys your customers create themselves

> Let signed-in customers create their own read-only API keys for your data, without exposing your Airtable token.

Give customers programmatic, read-only access to their data through your app, with keys they manage and you can revoke.

Sooner or later a good customer asks for an API. They want their orders in their own system, their
bookings in a spreadsheet, their stock levels in a dashboard. With Airtable behind your app, the
options are bad: hand over your Airtable token, which opens your whole base, or build an API layer
of your own.

VibeKit adds that layer for you. Switch on **self-service API keys** and your signed-in customers
can create, list and delete their own keys from inside your app.

## Read-only, and only what you choose

Every customer key is read-only. You decide which of your app's queries a key may read, so a key can
reach the order history you chose and nothing else. Your Airtable token never moves: keys talk to
VibeKit, and VibeKit talks to Airtable (see [token security](/products/vibekit/features/secure-token-vault)).

## You stay in control

- **Who can create keys.** Limit it to certain customer groups, for example paying plans only.
- **How many.** Each customer can hold up to five keys by default, and you can change the limit.
- **Revoke anything.** Customers delete their own keys, and you can block or delete any key at any
  time.

Each key is tied to the customer who created it, so you always know whose integration is calling.

## Built in, not built by you

Your coding agent adds the key-management screen with three calls from the VibeKit client: create,
list and delete. There's no key store to design, no hashing to get right and no separate API to
host.

## Questions this page answers

- give customers api access to airtable data
- customer api keys for an airtable app
- read-only api for airtable without sharing the token
- self-service api keys for a portal

---

Part of [VibeKit](/md/home.md) — all pages: [llms.txt](/llms.txt)