TL;DR:
Every button and form on a website sends a request. An assistant can turn those into named actions.
One action such as search for flights replaces filling five fields and clicking a button.
DuckyHelper learns a site's actions as small JavaScript tools. This is early access.
When you search for a hotel, you pick a city, two dates and a guest count, then press Search. It feels like five separate things. To the website, it is one: a single request carrying those five values. If an assistant can make that one request directly, it can skip the typing and the clicking.
The short answer
A website's interface is a front for requests to a server. If an assistant works out which request a form sends and what each field means, it can wrap that as a named action with inputs, for example searchStays(city, checkIn, checkOut, guests), and call it directly.
What happens step by step
Observe. Watch what the page does when a person uses the form.
Name the action. Give it a plain name and list its inputs.
Write a small tool. A short piece of JavaScript that fills the form fields or sends the same request.
Call it. Next time, call the action with new values.
Read the result. Turn what comes back into something readable.
Walk-through: a booking site's search form as one action
The form has city, check-in date, check-out date, number of guests and a Search button.
Input | Example value |
|---|---|
city | Lisbon |
checkIn | 2027-03-10 |
checkOut | 2027-03-13 |
guests | 2 |
Done by hand, that is: click the city box, type, pick a suggestion, open the calendar, pick two dates, set guests, press Search. Done as an action, it is one call with four values, and the results come back ready to read. Nights, if you want to confirm, are 13 − 10 = 3.
// An illustration of a learned action, not a real product API
searchStays({ city: "Lisbon", checkIn: "2027-03-10", checkOut: "2027-03-13", guests: 2 })What a request looks like
When you press Search on a booking site, your browser sends a message to the site's server. The message names the page it wants and carries the values you chose, such as city and dates. The server answers with the results, and the page draws them. The buttons and fields are a friendly way to build that message.
An assistant that understands which values go into the message does not need the friendly part. That is the idea behind turning a form into an action: keep the message, drop the manual filling.
What makes a good action
A plain name that says what it does, such as
searchStays.Clear inputs with types: text, date, number.
A readable result, so what comes back can be shown to you.
A limit on what it does. A search is safe to run repeatedly. A purchase is not, and should ask first.
Why small JavaScript tools
Pages already run JavaScript in your browser, so a short script can fill fields, press buttons or read results in the page's own terms. Small tools are easier to check than large ones.
A second example: a library catalogue
A library site has a search box and a filter for "available now". Two inputs: a search term and a true/false flag. A learned action findBook(title, availableOnly) returns a list with titles, branches and whether each copy is on the shelf. Ask for "Dune, available only" and you get the shelf list in one step, where clicking would have meant typing, ticking a box, pressing Search and scrolling.
Notice what stays with you: choosing which branch to visit, and reserving a copy if the site offers it. Reading is safe to repeat; reserving is a choice that is yours.
Reading actions (search, list, export) are low risk.
Writing actions (submit, send, buy) should ask first.
Each action should be small enough to check at a glance.
What it can't do
Work on every site. Some pages are built so the form cannot be reproduced safely.
Survive every redesign. If the site changes, the learned action may stop working.
Decide for you. Choosing which hotel to book is still your call.
Privacy and control
Learning a site's actions is part of how DuckyHelper works in your apps, and it is early access. It's built to ask first before it sends a message or pays for anything, and not to type your passwords or card numbers.
Try it yourself
Open a site you use weekly and write down the five things you do on it. For each, name the inputs. That list is the set of actions an assistant would need to learn.
An action is only as good as its edges. Before you rely on one, ask three things: what does it need from me, what does it return, and what can it change? A search that only reads is safe to run a hundred times. An action that submits an order changes the world, so it should ask you first, show what it is about to do and be easy to stop. Thinking of a site as a short menu of such actions, each with clear inputs and clear effects, also makes it easier to describe what you want: you are choosing from the menu and filling in the blanks.
If a site is large, the menu may have dozens of actions. That does not mean you need to learn them all. An assistant only needs the ones for the task you gave it, and it can learn others as you ask for them.
Frequently asked questions
Is this the same as a public API?
No. A public API is published by the site. Here the assistant works out actions from how the site's own page behaves.
Why not just click?
Clicking works everywhere but is slower and breaks more easily. A learned action is quicker when it applies.
Get started
