Developer terms and review guidelines

The guidelines

1. Do what the listing says, and nothing else.
2. Ask only for the permissions you use, and explain each one in your description.
3. No tracking of site visitors, no adverts injected into sites, and no data sent anywhere the site owner wasn’t told about.
4. Readable code. Nothing minified or obfuscated beyond normal bundling; reviewers must be able to read it.
5. No secrets in the code. API keys belong in your extension’s settings (config fields), which Webfaze stores encrypted.
6. At most one notice on your extension’s own settings screen; no nagging elsewhere in the admin.
7. Free stays usable. A paid upgrade may add features, but must not cripple the free version after install.
8. Keep a support channel open (your extension’s forum on webfaze.com counts) and answer within a reasonable time.
9. Fix security problems quickly. A version with an unfixed security problem can be pulled, which switches it off on every site.
10. Honest listings. Screenshots show the real extension; no fake ratings, other brands’ logos or misleading names.

What the automatic checks refuse

• Anything Webfaze itself refuses at install: eval, new Function, dynamic import(), system modules (file system, processes, raw network), and attempts to escape the sandbox.
• A manifest name that doesn’t match your listing, or a version that isn’t higher than the approved one.
• Wildcard or private network hosts, tracking services, and anything that looks like a key or token.
• Bundles over 600 KB.

Review times

New extensions: usually within 5 working days. Updates: within 2. Updates that ask for no new permissions are quicker to read.

Your rights and ours

You own your code and choose its licence. By publishing you allow Webfaze to host, review, sign and distribute it through the directory. We can refuse, pull or remove an extension that breaks these guidelines, always with a reason, and you can reply to the decision.