Guides
Teams, API keys and policies
Private recipes for your organization, API keys, and the policy admins can set for every member.
The public recipes are free and need no account. An account on wield.run adds what makes Wield work for your own sites and your team:
- private recipes, built by recording (guide) or published from your own files;
- an organization with members, roles (owner, admin, member) and shared private recipes;
- policies that apply to every member's Wield;
- API keys that connect your Wield to all of the above.
Plans and prices are on wield.run/pricing.
API keys
Create a key in your dashboard on wield.run. It looks like wld_ followed by 32 characters and is shown once. wield.run stores only its hash, so a lost key can't be recovered; revoke it and create a new one.
| Scope | Allows |
|---|---|
registry:read | Fetching your organization's private recipes |
policy:read | Fetching your organization's policy, and with it the key that signs your private recipes |
builder:run | Building recipes from recordings |
recipes:write | Publishing private recipes |
Give Wield the key in one of these ways:
- Claude Desktop bundle: the API key field when installing; edit it later under Settings → Extensions → Wield.
- Config file:
"api_key": "wld_…"in~/.wield/config.json. - Environment:
WIELD_API_KEY=wld_…in your AI app's server environment.
The key is sent only to wield.run, as Authorization: Bearer …. It never appears in logs or tool output; status shows its first eight characters. Without a key, or if it's rejected, the public recipes keep working.
Check it with npx -y wield-mcp doctor (the "Account" section) or by asking your agent for status.
Private recipes
Private recipes are stored for your organization only. They never appear in the public index and are served only with a key that has registry:read.
- Ids: your agent sees them as
<org>:<site>/<slug>, e.g.acme:intranet.acme.com/search-people, next to the public ones. - Signing: each one is signed with your organization's own key. Wield refuses a private recipe that isn't.
- Versions: they only go up. Publishing a new version leaves the old ones available for pinning and fallback.
- Publishing your own files:
PUT /api/v1/private/recipes/<site>/<slug>with arecipes:writekey. They get the same schema checks and lint as public recipes.
Organization policy
Admins set the policy in the dashboard. It applies to every member's Wield that uses a key of the organization:
| Setting | Effect |
|---|---|
| Allowed sites | Only these sites appear and run; others fail with policy_denied, and nothing is sent |
| Writes: deny | Write recipes don't appear and can't run |
| Telemetry: off | Outcome telemetry is off whatever members set |
A policy can only restrict. Nothing in it can widen what the extension allows, add sites the extension refuses, or skip the Allow window: every write still needs the user's click.
wield.run signs the policy with its registry key. wield-mcp checks it, enforces it, and passes it to the extension, which enforces it too. The last verified policy stays in force while you're offline or if wield.run can't be reached.
Organizations that manage browsers centrally (Chrome Enterprise, MDM) can also push the same settings to the extension as a managed policy. When both exist, the stricter one wins.