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 Authenticated Users

The Allow Authenticated (allowAuthenticated) access rule restricts access to callers with a valid, active login session.

It grants access to any registered user regardless of their specific role, organization membership, or permissions. It is commonly used for user self-service actions, community interactions, and establishing a global authentication baseline across an entire API.

1. How It Works

Section titled “1. How It Works”

Allow Authenticated verifies the caller’s session token at the very beginning of the request:

  • Who is permitted: Any authenticated user with a valid session token or cookie.
  • Anonymous callers: Automatically rejected with a 401 Unauthorized error before any database queries execute.
  • Database queries: None. The engine validates the user’s session in memory.
PropertySpecification
Rule TypeallowAuthenticated
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”
  • General User Actions: Creating a support ticket, posting a product review, or adding a comment to a discussion thread.
  • Self-Service Creation: Allowing any logged-in user to create a new workspace or register a new merchant storefront (POST /organizations).
  • Internal Platform Directories: Reading a directory of platform categories or tags available to all logged-in members.
  • Global API Baseline: Setting a global requirement at the API Model level so all endpoints require login by default.

❌ When NOT to Use

Section titled “❌ When NOT to Use”
  • Public Endpoints: Endpoints that should be openly accessible without login (use Allow Public).
  • Role-Restricted Actions: Administrative operations reserved for specific staff roles like admin or moderator (use Match User Role).
  • Private User Records: Viewing or editing personal profile settings, private notes, or invoices (combine with or use Match Resource Owner).
  • Multi-Tenant Scoped Data: Resources that belong strictly to a specific organization (use Match Organization Role).
Section titled “3. Recommended Modeling Patterns”

Pattern 1: Setting a Global API Security Baseline

Section titled “Pattern 1: Setting a Global API Security Baseline”

Instead of adding authentication rules to dozens of individual endpoints, you can attach Allow Authenticated at the API Model Level:

graph TD
    API["API Model Level<br/>(Scenario: Allow Authenticated)"] -->|Inherited by all entities| E1["Orders API (Requires Login)"]
    API -->|Inherited by all entities| E2["Invoices API (Requires Login)"]
    API -->|Overridden on specific actions| E3["Catalog API (Action: Allow Public)"]

All endpoints will automatically require login unless an individual action defines its own public scenario or enables “Override parent scenarios”.

Pattern 2: Multi-Tiered Endpoint Access (Privileged vs. Standard User)

Section titled “Pattern 2: Multi-Tiered Endpoint Access (Privileged vs. Standard User)”

When an endpoint serves different data to administrators versus standard logged-in users, place specific role scenarios before the broad Allow Authenticated scenario:

Article.list (Draft & Published Visibility):
├── Scenario 1 (Editorial Staff):
│   └── Match User Role: ['editor', 'admin']          <- Evaluated 1st: Sees drafts and published items
└── Scenario 2 (Registered Users):
    ├── Allow Authenticated                           <- Evaluated 2nd: Logged-in callers
    └── Lifecycle Status: ['published']                <- Injects filter: WHERE status = 'published'

Ordering Matters

Always place specialized role scenarios (such as Match User Role) above Allow Authenticated. Because Allow Authenticated matches any logged-in user, placing it first would cause it to claim the request before the specialized admin scenario is reached.

Pattern 3: Compound Scenario with Ownership Verification

Section titled “Pattern 3: Compound Scenario with Ownership Verification”

You can combine Allow Authenticated with a data-scoping rule inside the same scenario to ensure the caller is logged in before testing record ownership:

SupportTicket.read (Scenario: Ticket Author):
├── Rule 1: Allow Authenticated            <- Identity check: verifies caller is logged in
└── Rule 2: Match Resource Owner (author)  <- Data check: verifies caller owns the ticket
  • Anonymous Caller: Fails Rule 1 immediately →\rightarrow returns 401 Unauthorized without touching the database.
  • Logged-in Non-Owner: Passes Rule 1, but fails Rule 2 →\rightarrow returns 403 Forbidden.
  • Logged-in Owner: Passes both rules →\rightarrow returns 200 OK.

4. HTTP Status Codes Summary

Section titled “4. HTTP Status Codes Summary”
Caller StateEndpoint ConfigurationResulting HTTP Status
Anonymous (No token)Endpoint requires Allow Authenticated401 Unauthorized
Logged-in UserEndpoint requires Allow Authenticated200 OK / 201 Created
Logged-in UserScenario requires Allow Authenticated + Match Resource Owner, but user is not owner403 Forbidden

Next Steps

Section titled “Next Steps”