Skip to content
API Now LogoAPI Now LogoDocumentation
API Now! is currently in closed beta. We are constantly updating these guides as we release updates!

Allow Public Access

The Allow Public (allowPublic) access rule allows any client to access an endpoint without logging in or providing an authentication token.

It is the most permissive identity rule in API Now! and is ideal for exposing open data such as product catalogs, published blog posts, and documentation.

1. How It Works

Section titled “1. How It Works”

Allow Public acts as an open identity grant:

  • Who is permitted: Anyone—both anonymous visitors and logged-in users.
  • Authentication required: No. The engine passes the request immediately without checking for user credentials or session cookies.
  • Database queries: None. The identity check executes instantaneously in memory before any database interaction takes place.
PropertySpecification
Rule TypeallowPublic
Supported StrategiesRBAC, OrganizationRBAC, EnterpriseRBAC
Allowed Placement LevelsGlobal API Model Level, Exposed Entity Level, Action Level
Configuration OptionsNone (Zero parameters required)

2. When to Use & When Not to Use

Section titled “2. When to Use & When Not to Use”

✅ When to Use

Section titled “✅ When to Use”
  • Public Content: Exposing blog posts, news articles, product catalogs, or FAQs to web visitors.
  • Public Directories: Searchable catalogs or public directory listings.
  • Public Forms & Inquiries: Public contact forms, inquiry submissions, or feedback collection.
  • Health Checks & Status: System health endpoints called by uptime monitors.

❌ When NOT to Use

Section titled “❌ When NOT to Use”
  • User-Specific Data: User profile settings, private dashboards, order histories, or saved payment methods.
  • Multi-Tenant Workspaces: Endpoints where data must be restricted to verified members of a specific organization.
  • Sensitive Mutations: Update, Delete, or administrative actions that should only be performed by verified staff or resource owners.
Section titled “3. Recommended Modeling Patterns”

Pattern 1: Public Read / Authenticated Write (Standard Catalog)

Section titled “Pattern 1: Public Read / Authenticated Write (Standard Catalog)”

The most common API pattern for content and e-commerce platforms is allowing the public to browse data while restricting modifications to authenticated users or administrators:

graph LR
    subgraph "Article Entity"
        List["GET /articles (List)"] -->|Scenario: Allow Public| Pub1["Open to Public"]
        Read["GET /articles/:id (Read)"] -->|Scenario: Allow Public| Pub2["Open to Public"]
        Create["POST /articles (Create)"] -->|Scenario: Allow Authenticated| Auth["Logged-in Users"]
        Delete["DELETE /articles/:id (Delete)"] -->|Scenario: Match User Role| Admin["Admins Only"]
    end

Pattern 2: Public Published Items with Administrator Overrides

Section titled “Pattern 2: Public Published Items with Administrator Overrides”

When public users should only see published items, combine Allow Public with a data-scoping rule such as Lifecycle Status:

Article.list Scenarios:
├── Scenario 1 (Admin Workspace):
│   └── Match User Role: ['admin', 'editor']          <- Evaluated 1st: Sees drafts and published
└── Scenario 2 (Public Catalog):
    ├── Allow Public                                   <- Evaluated 2nd: Open identity
    └── Lifecycle Status: ['published']                <- Injects filter: WHERE status = 'published'

4. Ordering Best Practices: Avoid Broad-Before-Narrow Traps

Section titled “4. Ordering Best Practices: Avoid Broad-Before-Narrow Traps”

Because Access Scenarios are evaluated in top-to-bottom priority order, never place a scenario containing Allow Public before a specialized role scenario.

5. Security & Product Considerations

Section titled “5. Security & Product Considerations”

When opening endpoints to the public with Allow Public, keep these two product best practices in mind:

  1. Review Exposed Entity Properties:
    • When an endpoint is public, all properties selected in your Exposed Entity configuration are visible to anonymous callers.
    • Verify that sensitive fields (such as internal notes, supplier costs, or private user emails) are omitted from public exposure.
  2. Configure IP-Based Rate Limiting:
    • Public endpoints are susceptible to scraping and brute-force traffic.
    • Configure Rate Limiting on public endpoints using IP-based keying (type: 'ip') to protect your API availability without impacting regular users.

Next Steps

Section titled “Next Steps”