POST https://api.acedata.cloud/webextrator/render
The WebExtrator Web Page Rendering API is a web rendering service based on headless Chromium. Given a URL, it returns the fully rendered HTML (including content injected by JS), plain text, page title, and final URL.
Render is the lowest-level interface of WebExtrator. If you need structured extraction results (article body, product price, recipe ingredients, etc.), please use /webextrator/extract — it runs a complete set of typed extraction pipelines on the same rendering basis.
Application Process
To use the WebExtrator service page, first go to the Ace Data Cloud Console to obtain your API Token for backup.
If you are not logged in or registered, you will be automatically redirected to the login page inviting you to register and log in, and after completion, you will be automatically returned to the current page.
One API Token can call all services on the platform, no need to apply separately for each service. The first application will grant a free quota for a free experience; when the quota is insufficient, you can recharge the general balance in the console.
📘 Complete documentation: WebExtrator Service Page →
Authentication
All WebExtrator interfaces use standard Bearer Token authentication:Request Parameters
The platform contract uniformly uses snake_case. The internal rendering service supports camelCase, but external calls always use snake_case.
Cookie Structure
Synchronous Response
Asynchronous Response
Whenasync=true (or providing callback_url), it immediately returns (HTTP 200):
POST to callback_url (if configured), or actively queried through /webextrator/tasks.
Callback Structure
The platformPOSTs an envelope identical to the synchronous mode to callback_url, Content-Type: application/json. Returning any 2xx is considered confirmed; 5xx will be retried with exponential backoff for about 5 minutes.
Error Response
Error structure:
Example
cURL
Python (requests)
Node.js (fetch)
Asynchronous + Callback
{ "success": true, "task_id": "...", "trace_id": "...", "started_at": 1777717800.123 };
When the task is completed, the platform will POST the complete result to your callback_url.
Force Bypass Cache
Tips and Pitfalls
- Choosing
wait_untilcorrectly is important.networkidleis the most stable but slowest;domcontentloadedis fast but may miss asynchronously injected content;loadis suitable for traditional static pages. - Cache Key ignores
async. Synchronous and asynchronous requests for the same URL hit the same cache entry, switching freely will not invalidate it. - Cache Key ignores
bypass_cacheandcache_ttl_seconds. These two are operational switches and do not affect the response content. cookiesandheaderswill bucket cache. Customizing these two will cause the first hit of the same combination to fail.- Heavy SPAs often exceed the default 30 seconds. It is recommended to use
timeout: 60,wait_until: "domcontentloaded",delay: 4, and combine withwait_for_selectorto wait for the elements of real concern. block_resourcesis the fastest way to reduce latency. By default, images/fonts/media are blocked; if your extraction does not rely on CSS layout, addingstylesheetcan make it even faster.

