Dynamic content extraction succeeds when the returned text contains the page sections your task needs. Start with a standard Reader extraction on an accessible page. Use browser rendering when the required content is produced by JavaScript, then compare the returned body with the visible source. A nonempty response alone is not a completeness check.
Choose the extraction mode from page behavior
| Observed page | First action | Verification |
|---|---|---|
| Useful body in source HTML | Standard mode | Compare headings and supporting paragraphs |
| Application shell, body loaded by JavaScript | Rendered mode on a permitted page | Check the required runtime content |
| Content appears after a delay | Bound the wait in rendered mode | Confirm the specific missing section appears |
| Access denied or no permitted route | Record an extraction failure | Do not silently turn denial into empty success |
Keep request and client deadlines consistent
The Reader endpoint is POST /api/v1/url. Set t to url and s to the source URL. For a fresh check, use maxCache: 0. Browser rendering uses mode: 1; w is the bounded wait for that mode. The client deadline must allow for the requested work while still fitting the application deadline.
In the example below, the wait is a configuration choice, not a guarantee that the page finishes loading. A standard Reader extraction uses two credits. Rendering itself does not add a credit unit; the selected proxy can add credits.
{
"t": "url",
"s": "https://example.org/permitted-article",
"mode": 1,
"w": 2000,
"d": 30000,
"maxCache": 0,
"proxy": 0
}Record why a page passed or failed
Rendering is not a claim that every infinite-scroll item, authenticated view or interactive state is extracted. A bounded browser automation task needs its own stop condition and authorized fixture. This procedure verifies selected-page content, not model-answer correctness.
- Require an object at data and nonempty text at data.markdown.
- Compare the expected main heading, important paragraph, table and code sample with the returned content.
- Keep a missing-content result distinct from HTTP failure, API error and denied access.
- Use an explicit budget for retries and proxy changes; stop when it is exhausted.
Reference documentation: www.searchcans.com — /reader-api.
