How to contribute a public recipe to Wield
A public recipe is a JSON file that describes one task on one website. To contribute one, make it in one of three ways, pass the automated checks, run it live, and get a maintainer review. Recipes that sign in, solve bot checks or collect other people's data are not accepted.
Three ways to make one
- Record it. In the Wield extension, click Record, do the task once, then stop. The extension removes cookies, tokens, personal data and the values you typed before anything leaves your device. The builder drafts the recipe, and your own browser runs the draft's test plan. Hosted builds are part of the Pro plan.
- From a HAR file. This route is free and local. Record the task in Chrome DevTools, using Network with Preserve log, and save the capture as a HAR file. A HAR file contains your cookies, so keep it out of any repository. Then sanitize it on your machine with the builder's
tracecommand, and derive a draft from the trace. - By hand. Study the site's calls in DevTools, then write the JSON against the recipe format. Check it with
wield-build lint, and run it withwield-dev run.
Whichever route you take, the result must pass the checks below.
Before you submit
- [ ]
wield-build lintreports no errors. Warnings are read, and fixed or explained in the provenance notes. - [ ] The recipe ran live and passed its verify checks, in a browser or with
wield-dev. The submission gives the date and the method. - [ ] The task is something people would ask an agent to do, and the output answers it.
- [ ] Ads and sponsored results are dropped by default.
- [ ] The task is a short user-facing headline. The description says what comes back and what is filtered.
- [ ] The provenance says how each call was found, and it names every host outside the site's own domain.
- [ ] The terms note says what the site's terms say about automated access, if known, and how the recipe stays polite.
Automated checks
These run on every submission, and wield-build lint runs them all. Errors block publishing.
| Check | Rule |
|---|---|
| Schema and lint | The recipe matches the JSON Schema. Template references exist, JMESPath expressions compile, ids are unique, and step URLs stay on the listed origins. No Cookie or Host headers. |
| Every origin is used | Each listed origin is called by some step. |
| Named hosts | A host outside the site's domain is named and explained in the description or provenance. |
| Writes are marked | Booking, ordering and messaging calls are marked as writes, and the recipe declares an effect of write. |
| No secrets in the file | No token, API key or session value is written into the recipe. Tokens come from the session at run time. |
| No personal data | No email address, phone number, IBAN or card number appears anywhere, including the example parameters. |
| Request budget | A warning above 15 requests per run, and an error above 40. |
| Pacing | A loop of more than five requests sets a delay. |
Live verification
Lint cannot tell whether a recipe works, so every recipe runs live before it is public.
- Public reads pass their test plan in a browser, or with
wield-devwhere the site answers servers. - Login reads are run by the author while logged in. The login check passes when logged in and fails when logged out.
- Writes stop at the Allow window, which shows the summary. The author runs a live write only with their own data, and only if they want the effect. Until then, the recipe stays a draft.
After publishing, health checks run on public read recipes every day, as described in what happens when a website changes.
What we accept, and what we do not
We accept recipes for tasks that people do on a site with their own account or in public view. That covers searching, comparing, checking their own bookings, orders and messages, and, with the user's Allow, booking, ordering and messaging.
We do not accept recipes that:
- sign in, store or ask for passwords, or capture credentials in any way. Users log in themselves in their browser;
- solve, skip or work around CAPTCHAs, bot checks, rate limits or paywalls. If a site blocks automated requests, the recipe is not for us;
- collect other people's personal data, such as profiles or contact details, or download whole catalogues;
- send requests anywhere other than the site and the services it uses itself;
- contain code, obfuscated values, or requests that the description does not explain.
What reviewers check
Maintainers review each recipe against a short list:
- Destinations. Every origin belongs to the site, or is the site's own service and is explained.
- What is sent. Each step's URL, query, headers and body are read. Nothing from the session goes anywhere but the site.
- Reads really read. No request that changes state is sent without being marked as a write.
- Writes. The confirmation summary names who, what, when and how much.
- Output. Only what the task needs. No tokens, and no other people's personal data.
- Politeness. Request counts, loops and delays keep one run close to one person using the site.
- Evidence. The date, the method and the checks that passed are recorded.
- Terms. The terms note is honest. Sites that forbid automated access, or actively block it, are declined.
FAQ
Is my recipe public as soon as I submit it?
No. It goes through automated checks, live verification and a maintainer review before it is public. A team can also keep a recipe private, which is a paid-plan feature.
Which sites get recipes first?
The most-requested sites are built first. You can see the public request list on the sites page.
Where do I report a broken recipe?
Use the Report button on the recipe's page, or ask your agent to call request_recipe with the site and what failed. Security problems go to the privacy contact, not to a public issue.
Will you accept a recipe for a site that blocks bots?
No. Recipes that solve, skip or work around bot checks are not accepted. If a site blocks automated requests, the recipe is not for us.