Architecture and ownership

@incld sits beside your application, not in front of it. Your application remains the source of truth for users, organizations, permissions, and business side effects.

Interactive request path

User → React component → same-origin framework route → @incld API
              │
              ├─ resolves your authenticated session
              ├─ strips client-supplied identity recursively
              ├─ checks authorize({ operation, resource })
              └─ adds project secret + trusted identity

Browser components use IncldBrowser. It accepts only a relative base URL and has no API-key option. The framework route forwards a static list of methods and paths; it is not a general-purpose reverse proxy.

Asynchronous delivery path

@incld scheduler / bulk worker → signed webhook → framework adapter
                          │
                          ├─ verifies timestamp + HMAC
                          ├─ resolves declared action identifier
                          └─ calls action.run({ payload, event, client })

A schedule creates durable runs. A Bulk operation creates durable chunks. Both dispatch through the same action registry but provide different payloads. Delivery can be retried, so the event ID is exposed as an idempotency key.

Who owns what

Concern	Your application	@incld
Identity	Users, sessions, organizations, roles, permissions	Consumes trusted external identifiers
Authorization	Whether a user may request, view, decide, schedule, or cancel	Enforces project/component entitlement and lifecycle validity
Business action	The code that sends, exports, publishes, syncs, or mutates	Declares and delivers the action reliably
Durability	Idempotent side effects and application records	Schedules, runs, approvals, decisions, policies, chunks, retries, events
UI	Placement, product copy, surrounding navigation	Accessible workflow components, states, theming, and hooks
Operations	Application logs and domain alerts	Control plane, delivery status, usage, and cross-component Audit

Component boundaries

The first project on an account receives Schedules, Approvals, and Bulk on the permanent Developer plan. Each metered component has its own monthly hard limit and can be upgraded independently. API routes remain entitlement-gated, and Audit unlocks when at least one paid component subscription is active.

Free means production-capable

Developer uses the same APIs, SDKs, React components, durable state, and operational controls as a paid upgrade. It does not require a card or expire; only monthly capacity and the one-project allowance differ.

Actions are shared infrastructure

Schedules and Bulk refer to the same stable action identifier. Define an action once, synchronize its metadata, and use it from either component. Approval actions are business verbs such as publish; they are not executed automatically.