Frequentlyaskedquestions

Authentication

Do you handle end-user authentication for client portals?

Yes. VibeKit handles sign-in, sessions and access checks for your portal's users. It's passwordless by design:

• Magic link: a sign-in link sent by email. Each sign-in email includes the link and a 6-digit one-time code, and your user can use either. They're single-use and expire after 15 minutes.
• Google sign-in.
• Optional in-person code: a low-security code stored in an Airtable field, meant for things like kiosks or classrooms. It's off by default.

Because nobody has a password, there's no password reset flow. Nobody has a password to forget, reuse or leak. Email verification comes built in with email and Google sign-in: signing in proves the person controls that address.

You also configure:

• Which login methods are enabled.
• Which Airtable table, view and email field define your users. The view is the access boundary: only people in that view can sign in.
• Whether new people can self-register. When self-registration is off, only people already in your users view can sign in. You can also limit it to specific email domains.
• Session length. The default is 7 days, and you can set anything from 1 hour to 1 year.
• Re-checks against Airtable. By default, every signed-in user is looked up in Airtable again about once an hour. If you remove someone from your users view, or they no longer match a group's conditions, their access is revoked and open sessions are signed out.
• Your own email sender and your own Google OAuth client. You can use your own, or VibeKit's shared ones.
• Sign-in rate limits. Defaults cover sign-in emails and code guesses, and you can add optional caps per app and per group.

---

Authorization and data access

Can you enforce server-side permissions so each customer only sees their own records, even if they change URLs or API requests?

Yes. This is the core of the platform.

• Your portal never calls Airtable directly. It talks to the VibeKit proxy, which holds your Airtable token encrypted on the server. Your token never reaches the browser.
• No Airtable IDs in the browser. The portal only holds opaque handles for its queries and sealed, per-app tokens for records. Base, table, view, field and record IDs stay on the server. If a crafted or tampered token is sent, the proxy returns "not found".
• Every request is authorized on the server. Each query is set up once on the server, with its table, view, allowed operations, allowed fields and row rules. The portal can only name a query by its handle. It can't point a query at another table or remove its rules.
• Login is required by default. New queries require a signed-in user. A request without a valid session gets nothing.
• Row-level rules. You can attach server-side row rules to a query, such as "only rows whose Email is the signed-in user's" or "only records linked from the signed-in user's record". These rules are added to every read, re-checked on single-record reads and updates, and filled in automatically on create. The client can't see, remove or widen them. If a rule can't be resolved, the read is refused; it never falls back to returning everything.
• Field-level rules. Each query can be limited to a fixed list of fields. Other fields are never returned, and they can't be used to filter or sort. We recommend pinning a field list for every portal query; if you don't, the query exposes all the table's fields.
• The cache respects each user's rules. Cached results are stored per query, including each user's own row rules, so one customer's results are never served to another.

Can one company account have several users who see the same vehicles, invoices and work orders?

Yes. Store the company on each user's record as a link to a Customer record. Then chain two queries:

1. "My company": records linked from the signed-in user's own record, i.e. their Customer.
2. "Company vehicles / invoices / work orders": records linked from that Customer record.

The server checks that the Customer record belongs to the signed-in user before it returns anything linked to it. So every user at that company sees the same records, and nobody sees another company's.

To add or remove someone, change their user record in Airtable. Access follows on their next sign-in or re-check.

You can also define groups (for example "Company admin" and "Viewer") based on fields on the user's Airtable record. Queries can be limited to specific groups, so different people at the same company can do different things.

Can permissions be configured per table, field and action?

Yes, and you can change them at any time without rebuilding the portal.

Each query allows a specific set of operations: list, get one record, create and update. There's no delete operation.

For your example:

• Invoices and work orders: list + get only (read-only).
• Contact details: get + update, with the query's field list pinned to phone and email, and a row rule so users can only update their own record. Any attempt to write another field is rejected.
• Service requests: create only, with a pinned field list. New rows are automatically stamped with the signed-in user or company.

You can also enable public forms on a query. They let people who aren't signed in create records, for example a "request a quote" form. Public forms are limited to a pinned list of fields and rate-limited per visitor.

Changes to a query's permissions take effect on the next request, and the portal's code doesn't change.

---

Read-only production and development bases

Can the production Airtable base be connected with strictly read-only permissions?

Yes. Two separate layers enforce this.

Layer 1: VibeKit query permissions.

• Every query VibeKit creates is read-only by default: list and get.
• A query can only create or update records if you deliberately enable those operations and choose which fields can be written.
• If a query only allows reads, any attempt to create or update through it is rejected by the proxy before it reaches Airtable.
• Nothing in VibeKit can delete records.

Layer 2: your Airtable token.

• You connect your base with an Airtable Personal Access Token that you create, with the scopes you choose.
• For a read-only portal, give it data.records:read and schema.bases:read, and leave out data.records:write.
• Airtable itself will then refuse any write, whatever the app or its configuration asks for.

Schema: VibeKit never modifies your schema. It only reads it to learn table and field names and types. It doesn't need, and never asks for, schema-write access.

If your AI coding agent suggests a schema change during setup, such as an optional "Refresh cache" field, it makes that change through your own Airtable connector, where you can see and decline it. It never goes through VibeKit.

Can the agent build against a duplicated development base, then connect the finished app to production in read-only mode?

Yes. Here's how the hand-off works.

• Build on a dev copy. You and your agent can build and change the schema freely on a duplicate base. The agent makes those changes through your own Airtable connector, which you point at the dev base.
• Queries are tied to one base. Each VibeKit query is registered against a specific base, table and view, and addresses fields by their internal Airtable field IDs. That way, renaming a column never breaks the portal. There's currently no one-click "switch base" setting.
• Moving to production:
  1. Make sure the production base has the tables and fields the portal uses.
  2. Connect production with a read-only token.
  3. Have the agent register the portal's queries against the production base.
  4. The portal's code is updated to use the new query handles.
• What stays the same: your auth settings, access rules and design carry over, and the agent can do most of the work.

Because VibeKit never writes schema and every query starts read-only, many teams also build directly against production with a read-only token. They keep a duplicate only for trying out schema changes.

---

Performance and Airtable API limits

How do you handle Airtable API limits? Do you provide caching, batching or retries?

Your portal never queries Airtable directly. Every request goes through VibeKit's proxy on Cloudflare's global edge network.

• Caching (stale-while-revalidate): cached results are returned instantly. If they're older than the query's freshness window, a fresh copy is fetched in the background. You set the window per query (default 60 seconds, up to 24 hours), or mark data as always live.
• Refreshing the cache: writes made through the portal clear the affected cache entries straight away. For edits made directly in Airtable, you can add a small "Refresh cache" formula field or an Airtable automation script, so changes show up in the portal immediately rather than when the window expires.
• De-duplication and throttling: identical requests arriving at the same time are merged into one Airtable call. Calls from each app to a base are throttled to stay under Airtable's 5 requests-per-second limit per base. If several apps share one base, each has its own throttle.
• Batching: lookups of many records by ID are grouped into as few Airtable calls as possible.
• Retries: we don't automatically retry requests Airtable rejects for rate limits. The throttle is designed to avoid hitting them.
• Live updates: portal screens can subscribe to changes. When data changes, open screens are notified and refresh.

In practice, hundreds of end-user actions become a small number of Airtable calls.

---

Data storage and compliance

Do you cache or store Airtable data on your infrastructure?

Airtable stays the source of truth. VibeKit doesn't copy your tables into a database of its own.

Cached query results

These live in Cloudflare's edge cache (the Cache API), not in a database we run. Cloudflare evicts them on its own schedule, and they're cleared whenever the data changes. Attachment files shown in the portal are cached the same way.

What else we keep, and for how long

What	Why	How long
An encrypted copy of each signed-in user's own Airtable record	To apply their access rules without querying Airtable on every request	While the user has access; refreshed on each re-check
A short-lived copy of the signed-in user's record	To keep their live session up to date	Deleted 30 minutes after they disconnect
Sign-in events (email, method, result)	Security and troubleshooting	90 days
Request logs (no field values)	Monitoring	30 days
Files uploaded through portal forms	Airtable fetches each file once and keeps its own copy	Held briefly
Your app's configuration, and your Airtable token (encrypted)	To run the portal	While the app exists

Everything runs on Cloudflare's infrastructure.

Do you support EU data residency, GDPR and DPA requirements?

We're currently reviewing EU data residency, GDPR and DPA options, and we'll share details when they're ready. If this is a requirement for you, please get in touch so we can keep you updated.

---

Code ownership

Who owns the generated application code? Can we export it and run it independently?

You own your portal's code. Your AI coding agent generates it in your own repository, on your own machine, using a standard framework (React + Vite by default; Next.js, SvelteKit, Vue, Nuxt, Angular and Astro are also supported). You deploy it wherever you like: Cloudflare Pages, Vercel, Netlify or your own hosting. You can edit, extend and keep it indefinitely.

The VibeKit backend belongs to us. Authentication, authorization, the cache and the Airtable proxy are a hosted service that we run and maintain. For security reasons, the source for this layer isn't shared or offered for self-hosting.

Your portal uses VibeKit through a small client file included in your project, under our Terms of Service. To run the portal fully independently of VibeKit, you'd replace that layer with your own backend for sign-in, access rules and Airtable calls.

---

Pricing

How is pricing calculated, and what's included?

Everything is currently free while we finish setting up billing. When paid plans launch, pricing will be flat and monthly, based on how many projects you run:

Plan	Price	Projects
Personal	$12 / month	1
Professional	$24 / month	5
Unlimited	$96 / month	Unlimited

• No metering: there's no per-seat, per-record or per-API-call charge.
• Airtable: stays on your own Airtable plan.
• End users: each plan includes a generous monthly active end-user allowance. If an app consistently runs well beyond it, we'll contact you to agree a larger plan rather than interrupt a running project.

Full details: https://vibekit.aextra.ai/pricing

---

Overall

Beyond helping the AI understand and connect to Airtable, what production infrastructure does VibeKit provide?

VibeKit provides the backend a production portal needs, so you don't have to build and secure it yourself:

• Authentication: passwordless sign-in (email link or code, Google), sessions, self-registration controls, and automatic sign-out when someone is removed in Airtable.
• Authorization: server-enforced row and field rules, per-query operation permissions (list, get, create, update), groups, and chained "my company's records" scoping. It all fails closed.
• Backend API: a secure proxy between your portal and Airtable. Your Airtable token and IDs never reach the browser.
• Caching and rate-limit protection: an edge cache with configurable freshness, instant refresh on changes, request merging, and per-base throttling that keeps you within Airtable's limits.
• Abuse protection: rate limits on sign-in, public forms and data requests.
• Live updates: open screens are notified when data changes.
• File uploads: form uploads are checked and passed on to Airtable.
• Monitoring: request metrics, usage, query statistics, sign-in logs and email alert digests.
• Guided deployment: step-by-step deploy instructions for Cloudflare Pages, Vercel or Netlify.

With a general coding agent alone, you'd get a UI quickly, but you'd still need to design, secure, host and maintain all of the above. The hardest part is the authorization layer: guaranteeing that customer A can never see customer B's records, even when someone tampers with requests. That's usually where hand-built portals leak. VibeKit provides it built, enforced on the server and closed by default, so your AI agent can focus on the portal itself.