How to Monitor Multiple URLs in Wachete at Once
Monitor a prepared URL list in Wachete with multi-edit, discover related pages with crawling, or manage monitors through the REST API.
Short answer: For a prepared list of URLs, use Wachete’s multi-edit workflow: export monitor URLs and names to a text file, then copy and paste that text into the multi-edit box. For related pages you have not listed yet, use Wachete’s site-crawling option. For scripted setup, use the REST API to create or update monitors; the documented API does not establish an arbitrary-list bulk-import endpoint.
Choose the route based on where your URLs come from. Then set a suitable checking frequency and notification destination, and verify current plan limits before adding a large number of pages. Wachete runs monitoring on its servers, so your computer does not need to stay online. Wachete FAQ · Wachete REST API documentation.
1. Choose the right way to add multiple URLs
| Your situation | Use | What to know |
|---|---|---|
| You already have a list of individual URLs | Multi-edit | Wachete documents reusing exported URL and name text by pasting it into the multi-edit text box. The documentation does not specify the text-file delimiters or confirm which other settings it preserves. |
| You need to find linked pages on one site | Website crawling | Crawling follows links from a root page, can reach the third level of sub-pages, and supports URL filters in advanced settings. It may discover several hundred pages. |
| You need repeatable scripted setup | REST API | The API documents creating or updating monitor configurations, including recurrence, alerts, and crawl settings. Do not assume it accepts an arbitrary URL list in one bulk call. |
2. Reuse a prepared list with multi-edit
- In Wachete, open the monitor view and select the monitors you want to edit.
- Use the Edit or multi-edit workflow.
- If you have an exported text file containing monitor URLs and names, copy its contents and paste them into the multi-edit text box, as described in the FAQ.
- Review the resulting entries in the interface before saving. The published instructions do not define a file format, delimiters, or whether settings besides URLs and names carry over.
- Set or confirm the monitoring frequency and notification type for the monitors.
Wachete also describes exporting monitored URLs from Profile → Account as an Excel file. Its FAQ mentions exporting selected-monitor data for up to 20 monitors; that figure applies to that export operation, not to a general limit on how many URLs can be monitored or imported.
Prepare the list carefully
- Use the full address for each page, including the scheme such as
https://. - Keep names understandable if you will route alerts for many similar pages.
- Check for duplicate URLs and redirects that lead multiple entries to the same destination.
- After saving, open a few monitors and verify the target page, frequency, and notification route.
3. Discover pages by crawling one site
Use crawling when the page list is unknown or likely to change. While creating a monitor, choose the option to scan the root page and sub-pages. Wachete says it follows links, discovers pages through the third level, and lets you narrow matches with URL filters in advanced settings.
- Start monitor creation and choose the crawl or scan-sub-pages option.
- Enter the site’s root URL.
- Configure URL filters so the crawl targets the paths you actually want watched, such as a documentation or product section.
- Review the discovered pages and the resulting monitor count.
- Choose the check cadence and alert destination, then save.
Plan for scale: A crawl can find several hundred pages. That can consume more monitoring capacity and may require a paid subscription. Check Wachete’s current site and pricing information for live plan limits, prices, and check intervals; the available research did not establish current values.
4. Automate monitor setup with the REST API
Use the API when monitor definitions come from a script, deployment pipeline, or internal inventory. Wachete’s API documentation describes creating or updating monitors with a URL, monitor job type, recurrence, alerts, and notification endpoints. Portal crawling can also use crawl depth and URL filters, and the documentation exposes a dynamic-content setting.
Consult the official REST API documentation for the current endpoint paths, authentication method, request schema, and response format. Those details are not reproduced here because the retrieved documentation summary does not provide a complete runnable request or establish a bulk-list endpoint. A safe automation pattern is:
- Keep the desired URLs and per-monitor settings in a source file you control.
- For each entry, send the documented create or update request using that entry’s URL and configuration.
- Record the returned monitor identifier and result for each request.
- Retry only failed entries, and make retries safe by checking whether the operation creates a duplicate or updates an existing monitor.
- Verify a sample of created monitors in Wachete and confirm their alert destinations.
For crawling through the API, use the documented crawl depth and URL-filter parameters rather than generating a separate monitor for every discovered link, unless that is the intended configuration. Do not treat the FAQ’s “up to five source monitors” figure as an import limit: it refers to a Compute monitor that combines values.
5. Set frequency and notifications
Wachete’s creation flow asks for a monitoring frequency and notification type. Pick a cadence based on how quickly the monitored content changes and how quickly you need to react. A very large set of URLs checked frequently can increase plan usage, so confirm the current limits and intervals before scaling.
Documented notification options include email, mobile push, and webhook-based integrations such as Slack, Google Chat, Discord, Telegram, and Microsoft Teams. Route alerts to a destination that someone monitors, and test the notification path on a small set before depending on it for a large watch list. Monitoring runs on Wachete’s servers; a local script or device does not have to remain online for scheduled checks.
6. Troubleshoot common problems
| Symptom | Likely cause | What to try |
|---|---|---|
| A pasted list does not produce the expected monitors | The documented FAQ does not specify delimiters or the exact text syntax. | Export using Wachete’s own workflow, copy the exported text as-is, and inspect the result before saving. Avoid inventing CSV or newline rules; consult Wachete support or current interface guidance if the format is rejected. |
| The crawl produces too many pages | The root page links broadly across the site. | Add or refine URL filters in advanced settings, review the discovered-page count, and check plan capacity before enabling the crawl. |
| A page preview misses content rendered by JavaScript | The content may not be visible in the default static preview. | Switch the preview or monitor option to dynamic mode. Wachete says most pages can be monitored as static, but dynamic mode is appropriate when the desired content only appears after JavaScript runs. |
| The target returns “Forbidden” or does not load | The site may block automated requests. | First try the monitoring-location or dynamic-mode adjustments Wachete recommends. For bot-protected targets, its FAQ suggests a rotating residential proxy as an optional remedy. Proxy traffic can be high, especially for dynamic pages, and may add provider costs. |
| A monitor is created but no useful alert arrives | The notification type or destination may not match the intended route, or the check interval may be too slow. | Review the monitor’s frequency and notification endpoint, then verify delivery with a small test set. |
| API automation creates duplicates or partial results | Requests may be retried after an ambiguous response, or a batch script may stop partway through. | Track each URL and result independently, consult the API’s current create/update semantics, and retry only entries confirmed as failed. |
Wachete’s FAQ names Smartproxy and Oxylabs as examples of proxy providers, but proxy use is an exceptional workaround for blocked targets rather than a requirement for ordinary monitoring. Review the provider’s data-transfer pricing before routing dynamic pages through a proxy.
7. Performance, reliability, and cost planning
- Prefer filters over an unbounded crawl. Crawling can discover hundreds of pages. Narrow the URL scope first and inspect the result count.
- Match frequency to urgency. Use the fastest interval you need, while checking current plan intervals and capacity on Wachete’s live site.
- Keep automation observable. Log per-URL outcomes and monitor identifiers so partial API failures can be repaired without restarting the entire setup blindly.
- Account for dynamic pages. Dynamic monitoring may be necessary for JavaScript content, and Wachete warns that dynamic pages can transfer substantial data when used with proxies.
- Verify current costs before scaling. The research available for this article did not establish current Wachete prices or plan capacities. Crawling hundreds of discovered pages may require a paid subscription.
Or skip the browser setup
If your goal is to capture visual snapshots of pages rather than receive ongoing change alerts, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. Cookie and consent banners, newsletter popups, and chat widgets are removed before capture; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing result. AI agents can use its MCP server tools, including take_screenshot, get_page_info, and capture_pdf.
For a direct capture, replace the target URL and API key. See the ScreenshotNeo API documentation for the available options.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);ScreenshotNeo includes full-page and selector captures, 12 device presets and custom viewports, PDF settings, custom CSS and JavaScript, waits, request blocking, cookies and headers, caching, signed links, async jobs, bulk capture of up to 100 URLs per call, and a usage API. Its plans include 1,000 screenshots a month free with no card; paid plans start at $5 for 3,000, and every feature is on every plan. Sign up for 1,000 free screenshots a month, with no card required.
Frequently asked questions
Can I monitor unrelated URLs together?
The documented multi-edit workflow is the closest fit for a prepared set of separate URLs. Crawling is designed to discover linked sub-pages from a site root.
Does Wachete have a bulk API endpoint for any URL list?
The API documentation covered by this research describes creating or updating monitors, but does not document an arbitrary-list bulk-import call. Use the current API documentation to confirm available operations.
Do I need to leave my computer running?
No. Wachete says scheduled monitoring runs on its servers.
Is website monitoring the same as taking screenshots?
No. Wachete monitors pages for changes and sends notifications. ScreenshotNeo captures page images or PDFs on request, including bulk captures; it is not presented here as a replacement for Wachete’s ongoing change-monitoring workflow.
