Skip to main content
An app manifest is the input the SDK uses to build the sign-in capability request. It describes the app, the resources it needs, and any derived delegations it should request on the user’s behalf. Use a manifest when you want one sign-in flow to cover:
  • the app’s own data surface
  • any backend or agent permissions that should be bundled at sign-in
  • optional account-registry writes for the signed-in user

​
What the SDK does

During sign-in, the SDK resolves the manifest or pre-composed capability request, unions the requested permissions, and signs a single recap. For owned encryption networks, the SDK can also request tinycloud.encryption/network.create alongside tinycloud.encryption/decrypt so the network exists after sign-in. The manifest is not backend configuration. It is a client-side declaration that the SDK turns into a capability request before the user signs in.

​
What manifests are good at

  • keeping app permissions in one place
  • giving consent UIs and agents a readable summary of intent
  • describing app-scoped prefixes and default spaces
  • carrying optional knowledge-bundle metadata for agent-readable apps

​
What to avoid

  • do not treat a manifest as a substitute for server policy
  • do not duplicate exact permission syntax here if you only need the field list
  • do not invent a backend/delegation section that the SDK does not support

​
Reference

For the exact manifest fields, defaults, and composition rules, see App manifest reference. For the app-authoring bundle shape, see Agent-readable Apps.

​
Source note

The manifest behavior described here follows the TinyCloud JS SDK manifest composer and sign-in tests. The reference page contains the field-level shape.