Skip to main content
The manifest lists everything your app provides and everything it can access. You never write it: reintersect dev, reintersect deploy and the GitHub Action compute it from the exported app and sync it to Reintersect. Settings → Developer → Apps → your app → Manifest shows each version’s manifest read-only, and GET /v0/apps/:appId/manifest returns the published or latest preview manifest (API). To inspect it locally, call manifestOf:

Shape

Fields

Size limits

A manifest holds at most 50 blocks, 64 actions and 32 sections per block, 50 reference kinds with 50 patterns each, 10 message actions, 25 commands with 25 options each and 25 choices per option, 50 outbound hosts, 20 domains and 128 environment variables. Each JSON Schema is limited to 5,000 nodes and 256 KB once $refs are expanded, and the whole manifest to 50,000 nodes and 2 MB, with nesting up to 128 levels.

Validation

Reintersect validates the manifest whenever it accepts a version. It rejects a version with an invalid manifest with ReintersectAppManifestInvalidError and a reason, and existing installs keep working: Invalid reference patterns fail with ReintersectAppPatternInvalidError. reintersect check runs the same rules before you deploy. Reintersect computes each version’s access from:
  • scopes, egressHosts, domains and events,
  • block actions that aren’t readOnly, and actions that are destructive,
  • messageActions, and each message action’s context: thread and conversation count as more access than message,
  • mcp.url, and the MCP server’s tools that aren’t read-only or are destructive.
When you publish a version whose access adds anything, installs stay on their current version until a workspace admin approves the change, and your app receives app.reconsentRequired. These changes don’t widen access: changing a block’s layout, titles or descriptions, adding read-only actions, narrowing a message action’s context, and adding or changing commands. See Publishing new versions.