Scheduled FAQ
For capabilities, input sources, and shared settings, see the Scheduled overview.
For subscription requirements, charge components, and which team is billed, see Billing and usage.
How are web page fetches charged?
Web fetching consumes Credits based on the usage of each fetch. It is not a fixed 1 Credit per page and does not include subsequent Parser parsing charges.
More complex pages or stricter anti-scraping restrictions typically require more processing to retrieve the content, which can increase Credit usage.
For example, fetching a regular web page or blog post might cost just 1 Credit, while a website with stricter anti-scraping restrictions, such as X.com, might consume 30 Credits for one fetch. These figures illustrate differences in usage between websites; the actual charge depends on the usage of that fetch.
Unchanged content or a failed fetch does not waive fetching charges already incurred. See failed-run billing and billing for content changes and deduplicated results.
How are JSON API requests counted?
JSON API request attempts from all scheduled inputs in the same team are combined for each UTC day and charged at 1 Credit per 20 requests.
- Calculated daily: Each day’s total is divided by 20 and rounded down. The remainder is not carried into the next day. For example, 96 requests consume 4 Credits. Fewer than 20 requests produce no request charge and no zero-Credit history entry.
- Counted by attempt: Requests count even if they time out, fail, or return unchanged content. Runs blocked before reaching the request stage do not count.
- Settled later: Charges are settled after the daily window closes. Credit History does not show a charge for each request in real time. Charges may appear later, in the billing period when settlement occurs; the entry shows the usage date, request count, and Credits consumed.
These are API request charges only. AI parsing by Parser tasks created after fetching is billed separately.
Can a failed run still incur charges?
Yes. Charges depend on the fetching and parsing usage already incurred, not just whether the run succeeded.
| Situation | Charging rule |
|---|---|
| Web fetching fails or content is unchanged | Once a web fetch request is initiated, it is billed according to fetching usage. Unchanged content or errors such as 404 and 500 that prevent content retrieval do not waive fetching charges. |
| A JSON API request fails | Request attempts still count toward the daily total. |
| Fetching succeeds but Parser parsing fails | Fetching charges already incurred are not reversed. Parsing is billed separately under the normal Parser task rules. |
How am I charged when input content changes little or not at all?
Fetching and parsing are billed separately. No new output does not necessarily mean no parsing charges. There are two cases:
- No changes: fetching charges only, with no parsing charges. The fetched content matches the last successfully submitted input. No Parser task is created and no new parsing is performed. Fetching is still billed according to the source’s charging rules.
- Submitted: fetching and parsing are billed separately. Even a small input change can result in a Submitted status, which means a Parser task has been created and submitted for parsing. Parsing that has been performed still incurs charges even if all extracted results are removed as duplicates and no new content is produced.
Input change detection happens before parsing; result deduplication happens after parsing. Parsing charges are based on actual parsing usage, not the number of new rows ultimately produced.
For other topics, visit the FAQ directory.