feat(public-api): add env var and permission group controls to disable public API access

[waleedlatif1]

Summary

• Add DISABLE_PUBLIC_API / NEXT_PUBLIC_DISABLE_PUBLIC_API env vars to globally disable public API access for self-hosted deployments
• Add disablePublicApi permission group config option for enterprise admins
• Server-side enforcement: execute route returns 401, deploy PATCH returns 403 when disabled
• Consolidated public API toggle into existing PATCH /api/workflows/[id]/deploy route

Type of Change

• New feature

Testing

Tested manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	Feb 24, 2026 6:31am

[greptile-apps]

Greptile Summary

This PR implements a comprehensive public API access control system with both global and per-user controls. The feature adds DISABLE_PUBLIC_API environment variable for self-hosted deployments and disablePublicApi permission group config for enterprise admins to control public API access.

Key Changes:

• Added isPublicApi boolean column to workflow schema for toggling public access per workflow
• Server-side enforcement in execute route validates both env var and workflow owner's permission config before allowing unauthenticated access
• New PATCH endpoint on deploy route for toggling public API with permission validation
• Security controls prevent public API callers from injecting arbitrary workflow state or using draft versions
• Frontend UI in deploy modal allows toggling between API Key and Public access modes
• Code examples conditionally hide API key headers when public mode is enabled

Security Considerations:

• Public API requests execute as the workflow owner, with billing charged to the owner
• State injection vectors are blocked: workflowStateOverride is sanitized and sourceSnapshot is disabled for public requests
• Public requests always use deployed state, never draft state
• Both global env flag and per-user permission group config are enforced server-side

Confidence Score: 5/5

• This PR is safe to merge with proper security controls in place
• The implementation correctly addresses previous review concerns by validating both env var and permission group config server-side. Security controls properly prevent state injection attacks, and the two-layer approach (global + per-user) provides flexibility for different deployment scenarios.
• No files require special attention

Important Files Changed

Filename	Overview
apps/sim/app/api/workflows/[id]/execute/route.ts	Added comprehensive public API authentication logic with env var and permission group validation, plus security controls to prevent state injection
apps/sim/app/api/workflows/[id]/deploy/route.ts	Added new PATCH endpoint for toggling public API access with proper permission validation
apps/sim/ee/access-control/utils/permission-check.ts	Added validatePublicApiAllowed function and PublicApiNotAllowedError class for permission enforcement
apps/sim/hooks/use-permission-config.ts	Added isPublicApiDisabled computed property that merges env var and permission config
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/deploy/components/deploy-modal/components/general/components/api-info-modal.tsx	Added public API toggle UI with ButtonGroup for API Key vs Public access selection
packages/db/schema.ts	Added isPublicApi boolean column to workflow table with default false

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[User Toggles Public API in UI] --> B[api-info-modal.tsx]
B --> C[useUpdatePublicApi Hook]
C --> D[PATCH /api/workflows/id/deploy]
D --> E{Enabling Public API?}
E -->|Yes| F[validatePublicApiAllowed]
E -->|No| K[Update Database]
F --> G{Check DISABLE_PUBLIC_API env}
G -->|Disabled| H[Return 403]
G -->|Enabled| I{Check Permission Group}
I -->|disablePublicApi: true| H
I -->|Allowed| K
K[Update workflow.isPublicApi] --> L[Return Success]
M[Public API Request] --> N[POST /api/workflows/id/execute]
N --> O{Has Auth Credentials?}
O -->|Yes| P[Standard Auth Flow]
O -->|No| Q{Check workflow.isPublicApi}
Q -->|false| R[Return 401]
Q -->|true| S{Check DISABLE_PUBLIC_API env}
S -->|Disabled| R
S -->|Enabled| T{Check Owner Permission Group}
T -->|disablePublicApi: true| R
T -->|Allowed| U[Execute as Workflow Owner]
U --> V[Sanitize State Overrides]
V --> W[Force Deployed State]
W --> X[Execute Workflow]

Loading

_{Last reviewed commit: 9a65397}

[greptile-apps]

_{17 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (1)

apps/sim/app/api/workflows/[id]/public-api/route.ts
Only checks env var, not permission group config. Users in permission groups with disablePublicApi: true can still enable public APIs through direct API calls. Need to query user's permission group and check config.disablePublicApi similar to how use-permission-config.ts combines both checks.

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[greptile-apps]

_{19 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[greptile-apps]

_{19 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[waleedlatif1]

@cursor review

[waleedlatif1]

@cursor review

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

[greptile-apps]

_{19 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (1)

apps/sim/app/api/workflows/[id]/execute/route.ts
runFromBlock.sourceSnapshot not sanitized for public API

The workflowStateOverride is correctly blocked for public API callers (line 404), but runFromBlock with an inline sourceSnapshot is still allowed through. An unauthenticated caller can supply fabricated blockStates (previous block outputs) via runFromBlock.sourceSnapshot, which could be used to inject arbitrary data into downstream blocks — effectively bypassing upstream logic.

Consider sanitizing runFromBlock similarly to workflowStateOverride:

 if (rawRunFromBlock) {
// Public API callers must not inject arbitrary execution state.
// Only allow executionId-based snapshots (server-loaded), not inline sourceSnapshot.
if (isPublicApiAccess && rawRunFromBlock.sourceSnapshot) {
return NextResponse.json(
{ error: 'runFromBlock.sourceSnapshot is not allowed for public API access' },
{ status: 403 }
)
}
if (rawRunFromBlock.sourceSnapshot) {
resolvedRunFromBlock = {
startBlockId: rawRunFromBlock.startBlockId,
sourceSnapshot: rawRunFromBlock.sourceSnapshot as SerializableExecutionState,

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[greptile-apps]

_{19 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR