The Question: Can an Airtable Interface be public?
Teams often build a polished Interface from base data and then want to share a read-only link with external viewers. The common expectation is a public URL, similar to a shared view. Today, Airtable requires collaborators to access an Interface, which adds cost and onboarding overhead for large audiences.
Key points
- Interfaces are not publicly shareable at the moment
- Adding an external viewer makes them a collaborator
- Public read-only is a frequent request from the community
Implication: if you need a public dashboard, you will use a workaround that keeps sensitive data private while presenting a curated view.
Option A - Shared views for simple publishing
Use filtered and grouped grid or gallery views and enable public share. This gives you a stable URL and basic presentation.
Steps:
- Create a view with only the fields and records you want public
- Apply filters and sorting to match your intended story
- Use the Share and copy the public view link
Pros: zero code, fast setup, works well for lists and simple summaries.
Cons: limited layout control compared to Interfaces.
Option B - Low code sites that read Airtable data
Builders like Softr or Pory can read Airtable tables and let you design public pages with more control than a shared view. You decide which fields appear and who can see them.
Pros: friendlier layout options, auth gates if needed.
Cons: another tool to manage, feature limits on free tiers.
Option C - DIY frontend with a minimal API
Publish a small Next.js site and expose only derived or sanitized data. Keep your base secured and serve read-only content.
Suggested pattern:
- Add a read-only layer that maps raw records into safe fields
- Cache responses and set stale while revalidate headers
- Pre-render frequently accessed pages
Pros: full control of layout and performance.
Cons: requires engineering time and hosting.
Data safety checklist
- Remove internal identifiers that are not needed
- Avoid leaking collaborator names or emails
- Validate all filters server side, not only in the UI
- Set conservative cache rules for sensitive updates
Quick reference
| Goal | Recommended approach |
|---|---|
| Share simple lists or cards | Public shared views with filters |
| Branded marketing style pages | Softr or similar site builder |
| Fully custom dashboard | Custom frontend backed by a safe API |
Example: safe publishing with a bridge API
- Create a derived table that contains only public fields
- Sync or script population from your main base
- Serve the derived table to your website, not the source tables
This protects internal fields and reduces the chance of accidental disclosure.
Opinionated take
Public read-only Interfaces would unlock a lot of value. Until that exists, decide based on effort and risk: shared view for speed, site builder for polish, custom site for maximum control.
Further reading
- Community context: How to make link to Interface public