How many capabilities does EmDash define?

EmDash defines 11 capabilities covering network fetch (two variants), content reads and writes, media reads and writes, user reads, email sending and provision and interception, and page injection.

What happens if a plugin calls an API without declaring the capability?

The call fails at the runtime boundary. Capability checks are enforced at the point of use, not only at install time — so even dynamically-invoked calls are denied.

Do capabilities imply other capabilities?

Yes, in two cases: write:content implies read:content, and write:media implies read:media. Everything else must be declared individually.

Is network:fetch:any dangerous?

It is the broadest capability and gets the most scrutiny during audit. It grants unrestricted fetch, bypassing the allowedHosts list. Plugins should prefer network:fetch with an explicit allowedHosts when at all possible.

Capabilities reference

EmDash plugins must declare each capability they use in manifest.capabilities[]. The runtime denies any operation whose capability was not declared. There are 11 capabilities total.

Who this is for: plugin authors choosing the minimal set to declare, and site operators reviewing capability consent before install.

The full list

Capability	Grants	Typical use
network:fetch Requires allowedHosts. Preferred over network:fetch:any.	fetch() to hostnames listed in manifest.allowedHosts.	The plugin needs to talk to one or more specific third-party APIs.
network:fetch:any Scrutinised hard at audit. Prefer network:fetch where possible.	fetch() to any hostname. Bypasses allowedHosts.	The plugin genuinely needs arbitrary outbound fetch (rare).
read:content	Read any content document, field, or revision via the content API.	The plugin needs to inspect existing content — SEO analysers, search indexers, export jobs.
write:content	Create, update, and delete content documents. Implies read:content.	The plugin mutates content — migration tools, automatic tagging, form submissions.
read:media	Read media assets (images, files) from the site's media store.	The plugin inspects or re-exports media — image-processing helpers, CDN bridges.
write:media	Upload, replace, and delete media assets. Implies read:media.	The plugin generates or imports media — screenshot plugins, remote-asset mirrors.
read:users	Read user records (identity, roles) but not credentials.	The plugin personalises output, audits actions, or fans out notifications.
email:send	Send an email through the site's active email provider.	The plugin sends transactional or editorial email.
email:provide	Register as the site's email provider.	The plugin is an email backend — Postmark, Resend, UnoSend, SMTP.
email:intercept	Inspect outbound email before it sends. Can block or rewrite.	The plugin audits, routes, or tests outbound mail — compliance, sandboxing, preview.
page:inject	Add HTML to rendered pages via the page:metadata and page:fragments hooks.	The plugin injects meta tags, scripts, schema blocks, or widgets into output.

Declare the minimum

The marketplace audit is stricter on broad capabilities. A plugin that declares network:fetch:any or write:content when a tighter capability would do gets closer review — and reviewers are explicitly asked to flag over-declaration.

Some rules of thumb:

Read-only where possible. Declare read:content, not write:content, unless you actually mutate.
Use network:fetch with allowedHosts rather than network:fetch:any, even if it means listing 20 hosts.
Do not declare a capability “just in case”. It becomes user-visible at install consent and reviewers will ask what uses it.

Updated 2026-04-24. Previous: ← the manifest schema · Next: EmDash vs WordPress →