Wachete and Change-Monitoring APIs for Agents

You want an assistant that notices when a page, a price, or a record changes, and then tells you. That is what a change monitor is for. Wachete is one of those monitors. The useful part is the alert. The part that goes wrong is doing the follow-up twice because the alert arrived twice.

This article is about that double report. It is not a list of Wachete endpoints. The next section defines Swytchcode. After that are five change-monitoring agents you can start by pasting a prompt.

Wachete in the directory is here. How Swytchcode treats a failed call is in this article: How Swytchcode Retries Failed API Calls.

What Swytchcode is

Swytchcode is a production runtime for AI agents. The model decides which API call to make. Swytchcode runs that call. It is not the change monitor, and it does not merge two alerts into one by itself.

On every call it does eight checks:

1. Allow list. Only an action you added with swy add method can run.
2. Schema check. Inputs are checked against that action before the request is sent.
3. Policy. Rules in policies.json can allow, deny, or hold a call, and can read the arguments.
4. Credentials. The Wachete key is added when the call runs. It is not put in the chat. You store it with swy auth connect. There is no project env file for it.
5. Execution. The request goes from your machine straight to Wachete.
6. Retry. Swytchcode backs off on rate limits. A create or an update is retried only when an idempotency key is already set. Two alerts are still two inputs.
7. Response check. A success status whose body says the action failed is not treated as success.
8. Audit. The call and the policy decision are written to a local log.

Test or live mode is chosen once with swy init and stored in .swytchcode/tooling.json.

Change-monitoring agents you can build

Paste one prompt into Claude Code, Cursor, or Codex. Watch a page you control. The follow-up stays a report, not a write to another system.

1. Change list agent

Lists recent changes and stops there.

Set up https://www.swytchcode.com/skills.md and build a Wachete change-list agent. For the URL I give you, list recent changes. Do not open tickets, send email, or update any other system.

2. Morning digest agent

Turns the latest changes into one note for you.

Set up https://www.swytchcode.com/skills.md and build a Wachete morning-digest agent. Summarize changes since yesterday on the URL I name. If the same change appears twice, mention it once. Do not create tickets.

3. Duplicate-alert agent

Treats a repeated alert as the same change.

Set up https://www.swytchcode.com/skills.md and build a Wachete dedupe agent. When two alerts refer to the same page and the same edit, report them as one change. Do not run a follow-up action twice.

4. Price-watch agent

Reports the old value and the new value. It does not change a store.

Set up https://www.swytchcode.com/skills.md and build a Wachete price-watch agent. When the page I name changes, tell me the previous value and the new value. Do not update a catalog, cart, or email list.

5. Before-and-after agent

Compares the latest change with the one before it.

Set up https://www.swytchcode.com/skills.md and build a Wachete compare agent. Show the latest change on my URL next to the previous one. Read only. Do not write back to the page.

Polling, push alerts, and duplicate change events

Polling means your side asks, on a timer, "what changed?" If the timer overlaps, or the last answer was slow, you can see the same change in two polls.

Push means the monitor calls you when something changes. Networks repeat messages. A monitor can also send the same event again if it is not sure you received it. You can get two notices for one edit.

Neither style is wrong. Both need a rule for the follow-up. The notice is cheap to see twice. Creating two support tickets, sending two emails, or placing two orders is not.

Give the follow-up a stable reference built from the change itself: the page, and something that identifies this edit, not a random value created when the alert arrives. The second alert should find the first ticket, not open another. That note is an idempotency key. A longer explanation is Idempotency Explained.

Swytchcode retries the outbound call only in its own cases. A create or an update is retried when an idempotency key is set. Backoff applies when the provider says you are going too fast. That does not merge two Wachete notifications into one. If two alerts arrive, your follow-up has to recognize them as the same change. Do not expect the retry machinery to do that job.

Which change actions to turn on first

Turn on a read that lists recent changes. You want to see one change, once, in a test, before the assistant is allowed to write anywhere else.

Leave "create a ticket," "send an email," or "update the price" off until the reference for that write is stable. If the follow-up is hard to undo, have a person approve it. On Business and Enterprise that hold goes to Slack or Telegram, and silence for 48 hours means it does not run. Free and Pro can allow or deny. They do not include the hold.

Test mode is set with swy init --mode=sandbox and saved in .swytchcode/tooling.json. Watch a page you control, not a customer's production site, until you have seen a repeated alert stay as one follow-up.

Follow these steps to connect Wachete

swy is the short name for the Swytchcode program.

1. Follow this step to install the CLI

If you use Node.js:

npm install -g swytchcode

On Windows PowerShell:

irm https://cli.swytchcode.com/install.ps1 | iex

On macOS or Linux:

curl -fsSL https://cli.swytchcode.com/install.sh | sh

Then swy --version. Continue in the CLI quickstart.

2. Follow this step to sign in

swy login

See the authentication docs.

3. Follow this step to start in test mode

swy init --editor=claude --mode=sandbox

Use cursor or codex if needed. See Set up a project.

4. Follow this step to download Wachete

swy get wachete

This does not turn every action on.

5. Follow this step to find a list of changes

swy discover "list changes" --project wachete

Use the name it prints. Do not copy a method name from this article.

6. Follow this step to read the fields

swy info <id from discover>

Replace <id from discover> with the name from step 5. Run it after step 4.

7. Follow this step to turn that read on

swy add method <id from discover>

Do not add the follow-up write yet.

8. Follow this step to store the Wachete key

swy auth connect wachete

The key stays on your machine, outside the chat. Explore this article: credential brokering.

FAQ

What is the difference between polling and a push alert?

Polling is when you ask on a schedule whether something changed. A push alert is when the monitor tells you. Both can report one change more than once.

If Wachete fires twice, will Swytchcode ignore the second one?

No. Swytchcode's retry rule is about the call your side makes. Two alerts are two inputs. The follow-up action has to reuse a stable reference so the second one does not create a second ticket or email.

What should the reference be?

Something you can rebuild from that change, such as the page and the edit id the monitor gave you. Not a random value created when the alert was received.

Can the assistant see the Wachete key?

Not on this path. It is stored with swy auth connect wachete and added when the call runs.

Read next

• Explore this article on retries: How Swytchcode Retries Failed API Calls.
• How a repeated write is treated is in the idempotency guide.

Watch one page you control

Start at step 1 if the CLI is not installed. Ask the assistant what changed. Do not let it open a ticket until you have seen the same change arrive twice and produce one follow-up.

You can give Claude Code, Cursor, or Codex skills.md and ask it to follow these steps in test mode.

If a repeated alert created two results, tell us what the follow-up was. Discord is the quick place. The contact form works if the page you are watching is private.