Chinese AI Model Release Tracker Hugging Face
Pricing
Pay per event
Chinese AI Model Release Tracker Hugging Face
Track Chinese AI model metadata from Hugging Face with optional ModelScope enrichment, dated snapshots and honest changes in download indicators.
Pricing
Pay per event
Rating
0.0
(0)
Developer
Tim Zinin
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
5 hours ago
Last modified
Categories
Share
Track Chinese AI model releases through Hugging Face listing and detail metadata, with optional ModelScope enrichment. Export a dated model snapshot, source counters and carefully scoped changes against successful prior deliveries.
Evidence status: private build 0.1.3 accepted on 2026-09-06. Every input/output example below is an exact Dataset record from accepted runs on Apify's network with the pay-per-event tariff active. The listing is not public yet; no scheduled task or review history is claimed.
What you get
- HF listing plus exact-ID detail metadata
- Optional identity-checked ModelScope download enrichment
- First-snapshot flags and successful-delivery baseline state
- Signed download-indicator change per hour, with explicit elapsed window
- Runs on Apify: schedule it, monitor it, call it through the platform API, and export the dataset as JSON, CSV or Excel.
ModelScope enrichment checks the exact model name and organization: Data.Path may be the organization or the legacy full org/name, with a matching Namespace when supplied. A 404 mirror response yields modelscopeStatus: "not_matched" and null ModelScope downloads; other identity failures yield a free partial row. B3b fixtures use a ModelScope JSON body captured on 2026-09-06; the Hugging Face fields and SDK run remain synthetic/offline.
How to run it
- Open the actor input form and review the supplied prefill.
- Replace the scope with sources you are authorized to process, or use the reviewed prefill for a first check.
- Set a small result limit and an appropriate run budget.
- Start the run, then inspect both the dataset and the OUTPUT record.
- Filter complete rows before connecting an export or unattended schedule.
Pricing
Active tariff on the private build: $0.005 per run start + $0.002 per complete model record through the result-found event.
For 100 complete payable units, the planned event total is $0.205, including one start. Free absence, source errors, incomplete requested work and notices do not add a result event. A run-start event can still apply even when every result row is free.
Input
This is the schema prefill used for the key-free daily run contract. Optional secrets have no prefill. Array lengths and structural limits are checked again in the runtime before source work.
| Field | Meaning |
|---|---|
orgs | Hugging Face organizations. Up to 30 author names; baidu here is an HF author string, never a Baidu website request. |
sinceDays | Lookback days. Filter source lastModified against this UTC window. |
maxModels | Maximum model details. Up to 500 selected models; capped listings may omit further source results. |
families | Model ID family terms. Case insensitive substring matching against model ID, at most 20 terms of 80 characters. |
licenses | Exact license identifiers. Filter HF detail license, at most 20 identifiers of 80 characters. |
enrichModelScope | Enrich with ModelScope. Requested enrichment failure makes that model free partial; an unmatched model has null downloads. |
stateStoreName | Buyer key-value store name. Serialize schedules sharing selection settings; state writes follow confirmed delivery. |
onlyChanges | Only changed snapshots. Suppress unchanged successful baseline rows. The first snapshot has null isNew and isUpdated. |
Output
The record below is exact. Run gLkOVopetKp52AK7h on build 0.1.3, 2026-09-06, 9 s, Dataset records: 2, charged events: {"apify-actor-start": 1, "result-found": 1}. 1 paid record(s). Input: {"orgs": ["Qwen"], "enrichModelScope": true, "maxModels": 1, "sinceDays": 14, "stateStoreName": "china-model-releases", "onlyChanges": false}.
Other tools we built
Model metadata: source and identity contract
This tracker reads the Hugging Face model listing API by author and follows selected IDs to the model detail API. It does not download repository files, model weights, tokenizer assets, source code or Markdown model-card files. The metadata available in the API can include license and parameter evidence, but that is a different surface from executing or downloading the model itself.
Organizations are author filters on Hugging Face. The accepted default organization inventory includes Qwen, deepseek-ai, moonshotai, zai-org, MiniMaxAI, ByteDance-Seed, tencent, baidu, openbmb, internlm, stepfun-ai and XiaomiMiMo. The short daily prefill uses only Qwen, deepseek-ai and moonshotai. The string baidu in an author query does not cause a request to Baidu's website; fixed host and path allowlists keep that boundary explicit.
Each listing is requested in descending lastModified order with a bounded limit. Results outside sinceDays are filtered before detail work, as are IDs that do not match an optional family term. A malformed listing item is a source error, not an absent model. A listing that fills the requested limit is marked potentially truncated, because the actor cannot prove that there are no additional matching entries after that bounded page.
The detail contract checks the exact model ID, source dates, numeric downloads and likes, and the tag array. A source missing those required fields produces a free partial row. License and parameter count can be unavailable without making the source say a false value. In particular, a name containing “7B” is not treated as proof of seven billion parameters. Parameter evidence comes from an explicit safetensors total in the detail response; otherwise both the value and evidence are null.
The family filter is a case-insensitive substring match on the model ID. It is a buyer-controlled selection heuristic, not an authoritative model taxonomy. The license filter uses exact reported license identifiers from the detail metadata. A filtered model is outside this run's result set; filtering is not a claim that a repository disappeared, changed ownership or lost its license.
ModelScope enrichment and partial results
When enrichment is enabled, a selected HF model is checked against the matching ModelScope metadata endpoint on www.modelscope.cn. The returned envelope must report success, its code must match the successful API contract, and the returned identity must match the requested organization and name before fields are merged. Merely receiving HTTP 200 is not sufficient. An error object inside a 200 response remains an error.
A ModelScope HTTP 404 is a known unmatched record and produces modelscopeStatus:not_matched with null downloads. That is different from zero downloads on a matched record. A timeout, server error, malformed envelope, unsuccessful Data status or identity mismatch prevents completion of requested enrichment. The HF evidence may be included in a free partial row, but the row is not charged and cannot update the successful baseline.
Set enrichModelScope:false if your actual task requires only HF metadata. In that explicitly chosen contract, a complete HF detail is a payable result and ModelScope status is disabled. The actor does not silently switch to that mode when an enrichment request fails; silently changing the contract would hide which requested evidence was missing.
The allowed ModelScope host in this build is the www host required by the B3 brief. A redirect to an unapproved host is refused, even if the two hosts appear related. Such a refusal is a source-access limitation that must be reviewed against the accepted source configuration. It is not permission to expand the allowlist dynamically or to fetch repository files as a fallback.
Snapshots, changes and download velocity
The named key-value store belongs to the buyer account. Its selection key hashes the normalized selection settings, including organizations, filters, lookback, enrichment mode, maximum model count and change-only behavior. Changing any of those settings creates a separate comparison lineage. Keep the settings stable when your question is “what changed since the last comparable run?”
A first successful snapshot carries baselineCreated:true. On that snapshot, isNew, isUpdated, downloadVelocity and velocityWindowHours are null. There is no earlier paid observation to compare against, and the first snapshot is not a justified assertion that every model is newly released. isNew on later comparable snapshots means the ID was missing from the successful local baseline, not that a marketing launch occurred at that moment.
An existing baseline stores a fingerprint of the selected metadata and the previous download indicator. isUpdated compares fingerprints; it can change because likes, license, tags, timestamps or source counters changed. It is not a claim that the model's weights were inspected. Source edits and counter changes are useful metadata signals, but they should be labelled accurately in a release dashboard.
downloadVelocity equals the new HF download indicator minus the previous successful indicator, divided by elapsed hours. The HF indicator is a source-defined windowed metric. Its difference is not a count of newly downloaded files. A negative result is valid: the reported indicator can decrease. Do not clamp negative values to zero, call them data corruption by default, or rank them as negative real-world downloads.
The velocity window begins at the previous successful stored observation. A failed or unpaid row does not move that timestamp. If several runs fail and a later one succeeds, its rate spans the longer interval. A zero or negative elapsed interval cannot yield a meaningful hourly rate and is represented by null rather than infinity or an invented instantaneous value.
Baseline reads happen before network work. A read failure stops the run with an explicit state error; it is not treated as a first snapshot. Structurally damaged stored state is identified by baselineReset. Commits follow confirmed complete delivery. A state write failure after paid delivery fails the run and requires reconciliation: the delivered result may exist even though the comparison checkpoint did not advance.
The store is bounded to ten thousand entries. Old entries can be evicted when the retained selection history exceeds that limit. This is an operational cache, not a permanent all-model catalog. Export paid observations into your own historical table if you need a durable, arbitrarily long record. Parallel runs on the same selection key are unsupported because named KVS updates do not provide the required cross-run compare-and-swap transaction.
Model tracker interpretation examples
A model with HF downloads 100 at one paid observation and 80 one hour later has velocity -20 indicator units per hour. A likes increase with unchanged downloads can set isUpdated:true while velocity is zero. A repository seen for the first time after a changed filter can belong to a new baseline lineage and therefore have null first-snapshot comparison flags. These are calculation examples, not claims about current production models.
A license filter that excludes every complete detail produces an honest no_updates record after source success. An HF source failure with the same empty paid result set produces partial diagnostics instead. Those outcomes should route to different notifications: the first can be a quiet monitoring day, while the second deserves an availability or parser alert.
Rank reflects the order of delivered selected model rows in this run. It is not a leaderboard score, quality assessment, popularity percentile or ranking across all Chinese AI models. Since listings and output are bounded, a rank of one only describes the current run's surviving selection. Keep the orgs, sinceDays and maxModels settings alongside any chart that uses rank.
Field reference
Every field in the overview view is listed here, including diagnostic and notice fields that may be absent from a complete domain row. A missing optional domain field after pre-work validation means no corresponding source observation was made.
modelId
Exact organization/name identifier validated against the HF detail response. Use it as the model join key; keep the run ID to distinguish observations over time.
org
Organization portion of modelId and HF author selection. It is not a separately crawled company website or an independently validated legal entity.
name
Repository name portion of modelId. Digits or suffixes inside this string are not parsed as authoritative parameters, version claims or license terms.
createdAt
Source creation timestamp normalized to ISO UTC. It describes the HF metadata object and does not establish a marketing launch or earliest model availability elsewhere.
lastModified
Source modification timestamp used for the lookback and fingerprint. It can reflect a metadata edit, not necessarily a change to weights or code.
parameters
Nullable explicit safetensors total. A null value means the metadata surface did not provide the supported evidence; the actor never parses a parameter count from a name.
parameterEvidence
Nullable object naming the exact detail field behind parameters. Preserve it with the number when exporting a model inventory or making a comparison chart.
license
Reported license identifier from cardData or license tags. The identifier is useful for selection but is not a legal interpretation of every repository artifact.
pipeline
Reported pipeline_tag, when present. A null value means no supported metadata field was available, not that the model cannot be used in a pipeline.
tags
At most one hundred source tag strings. A warning identifies a longer source array. Tag text is metadata and is never executed or fetched as a URL.
downloadsHf
Nonnegative numeric HF download indicator from the detail API. Retain its source-window meaning rather than describing the value as a cumulative lifetime count.
downloadsModelScope
Numeric indicator only after a matched successful ModelScope envelope. Unmatched, disabled or unavailable enrichment must not be silently turned into zero.
likes
Nonnegative numeric source likes indicator. The actor reports the observed API value and does not infer unique people, purchase intent or endorsement quality.
modelscopeStatus
Matched, not_matched or disabled for the complete contract. Requested enrichment failure appears as partial/error; it is not treated as a matched record with missing downloads.
isNew
Comparison flag with actor-specific meaning. Model first baselines use null; news uses absence from successfully delivered seen-state. Read the state section before interpreting it.
isUpdated
Model fingerprint comparison against the previous successful entry. It is null on the first baseline and is not a claim that model files were inspected.
baselineCreated
Identifies a newly established model selection lineage. It cannot be used as evidence that all included models were just released to the public.
baselineReset
Signals structurally damaged prior state. A failed state read is a separate fatal error, never silently represented as an empty successful baseline.
downloadVelocity
Signed change in the HF download indicator per elapsed hour. Negative values are valid. It remains null without a positive comparison interval and prior successful observation.
velocityWindowHours
Positive elapsed hours between successful comparable snapshots. Failed or unpaid rows do not move the baseline time; a longer gap therefore widens this window.
rank
Order of delivered selected model rows in this run. It is scoped to bounded input and surviving filters; it is not a global model leaderboard or quality score.
scanned
Count of listing items inspected during source selection. It differs from detail requests, delivered rows and paid events; a full bounded listing can still omit an unknown tail.
sinceDays
Lookback window echoed on a no_updates model diagnostic. It helps explain a clean absence; compare it with the checked timestamp and scanned count.
filtered
Count of candidates excluded by the applicable selection stage. It is not a count of source failures or deleted upstream objects.
unprocessed
Known units left unfinished under the run contract. It does not invent an exact count for source pages the actor never fetched. Read cap warnings for an uncounted tail.
schemaVersion
Stable row-contract version. Use it when validating a downstream parser; a version label alone does not establish cloud acceptance or a live pricing configuration.
type
Row category such as model, article, audit, contacts, source or notice. Filter by type together with found and partial to keep diagnostic records out of business-result tables.
sourceUrl
Primary source surface for the observation. It points to permitted API/feed/robots/HTML evidence and is not an instruction to crawl additional linked resources.
found
True only for a complete payable unit. False covers both clean absence and partial failure, so combine it with status, error and partial instead of using it alone.
status
Domain-specific classification such as found, no_updates, no_contacts, no_data or partial. It conveys a more useful outcome than the platform run status alone.
resultCount
One on complete payable rows and zero on free rows. It counts this actor's billing unit, not nested objects, HTTP requests, tokens or discovered links.
partial
True when the row or run contract is incomplete. Useful partial evidence can remain in the dataset, but it is delivered without the result-found event.
error
Stable nonempty reason for a failed requested observation. Empty string is reserved for rows without a recorded error; it is never used to disguise unavailable sources.
warnings
Bounded interpretation or coverage notices. A warning does not automatically mean partial, so read the relevant domain contract and explicit partial flag.
checkedAt
UTC observation assembly time. It is distinct from source publication, creation or modification dates and should not replace unknown source timestamps.
evidence
Nested provenance describing the permitted source surface and minimal supporting fields or URLs. Retain it for review; it is not a permission certificate.
confidence
Categorical evidence description, not a calibrated probability. source_metadata indicates the source contract was assembled, not that every downstream interpretation is correct.
action
A small operational hint such as review or set_apiKey. It is descriptive output and never executes a browser action, sends a message or changes an external application.
Configuration cookbook
These are configuration examples, not additional source captures. Each example starts from the exact prefill and changes the shown scope. The stated result contract describes how to assess a run; it does not promise a currently available source result.
Start a comparable model baseline
Use the reviewed three-organization scope when learning the output. The first snapshot establishes comparison state for this exact selection, so new and updated flags are null rather than true.
Inspect modelId, license, parameterEvidence and modelscopeStatus. Keep the selection settings stable for the next comparable run.
Budget reference for this configuration: at most 6 payable units under the result limit, or $0.017 in planned start-plus-result events if that many complete units are delivered. This is a ceiling calculation for the configured limit, not a forecast of source yield.
Limit research to Qwen
An author filter changes which listing is requested. It also changes the selection hash, so it starts a separate baseline from a run that included other organizations.
Do not interpret baselineCreated on this selection as a new release by Qwen. It means this comparison lineage has no earlier successful state.
Budget reference for this configuration: at most 6 payable units under the result limit, or $0.017 in planned start-plus-result events if that many complete units are delivered. This is a ceiling calculation for the configured limit, not a forecast of source yield.
Monitor three organizations for changes
After the first successful snapshot, unchanged fingerprints can be suppressed. This mode uses its own stable lineage, including the onlyChanges setting.
A no_updates row means the current successful selection produced no changed deliverable models. It is not proof that the entire HF platform was unchanged.
Budget reference for this configuration: at most 6 payable units under the result limit, or $0.017 in planned start-plus-result events if that many complete units are delivered. This is a ceiling calculation for the configured limit, not a forecast of source yield.
Read HF without enrichment
Choose this deliberately when the task needs only HF metadata. The requested result contract then excludes ModelScope availability and downloads.
A complete HF row is payable. Its ModelScope fields say disabled and null; the actor never changes to this contract silently after an enrichment failure.
Budget reference for this configuration: at most 6 payable units under the result limit, or $0.017 in planned start-plus-result events if that many complete units are delivered. This is a ceiling calculation for the configured limit, not a forecast of source yield.
Apply an exact license filter
The filter is applied to reported detail license metadata. A source without that identifier is outside the selection even if its repository name sounds compatible.
Retain the source license string and evidence. The filter is not a legal review, a license text download or a guarantee that every artifact in a repository uses one license.
Budget reference for this configuration: at most 6 payable units under the result limit, or $0.017 in planned start-plus-result events if that many complete units are delivered. This is a ceiling calculation for the configured limit, not a forecast of source yield.
Focus on a model family string
Family terms are a bounded substring selection on the model ID. This is useful for a focused queue, but it is not an authoritative classification of architecture.
Review retained IDs before naming a dashboard after a model family. A string filter can omit aliases or include repositories that merely share a term.
Budget reference for this configuration: at most 6 payable units under the result limit, or $0.017 in planned start-plus-result events if that many complete units are delivered. This is a ceiling calculation for the configured limit, not a forecast of source yield.
Use a narrow one-day window
The window is based on source lastModified, so a valid narrow run can produce no_updates. A previously popular model is not substituted merely to keep paid rows flowing.
Route a clean no_updates row differently from a source failure. Compare source dates to the run UTC time when explaining an empty result.
Budget reference for this configuration: at most 6 payable units under the result limit, or $0.017 in planned start-plus-result events if that many complete units are delivered. This is a ceiling calculation for the configured limit, not a forecast of source yield.
Review a ninety-day metadata window
A longer window can expose more candidates, but each organization listing is still bounded. A full page produces a coverage warning instead of an exhaustive-catalog claim.
The result limit does not guarantee all ninety-day models were scanned. Use scanned, filtered and listingTruncated when reporting coverage.
Budget reference for this configuration: at most 50 payable units under the result limit, or $0.105 in planned start-plus-result events if that many complete units are delivered. This is a ceiling calculation for the configured limit, not a forecast of source yield.
Separate an experimental state lineage
Use a distinct buyer store when evaluating new filters or downstream rules. This avoids confusing a production schedule with an exploratory comparison series.
Store naming is not a concurrency lock. Serialize overlapping runs even when you selected a dedicated name.
Budget reference for this configuration: at most 6 payable units under the result limit, or $0.017 in planned start-plus-result events if that many complete units are delivered. This is a ceiling calculation for the configured limit, not a forecast of source yield.
Check only one selected model
This is a bounded smoke configuration for source and schema review. The listing can be marked potentially truncated because a single returned item fills its limit.
Inspect a complete row and its event separately from the free listing-cap notice. The rank belongs only to this tiny selected slice.
Budget reference for this configuration: at most 1 payable units under the result limit, or $0.007 in planned start-plus-result events if that many complete units are delivered. This is a ceiling calculation for the configured limit, not a forecast of source yield.
Use the accepted broader author inventory
The author list remains entirely on huggingface.co. It is not a crawl of the corresponding companies or their social accounts.
Expect source coverage to depend on the authors and bounded listings. Keep the author strings with exported comparisons to avoid implying ecosystem-wide completeness.
Budget reference for this configuration: at most 30 payable units under the result limit, or $0.065 in planned start-plus-result events if that many complete units are delivered. This is a ceiling calculation for the configured limit, not a forecast of source yield.
Exercise a correct empty scope
An explicitly empty organization array is a deterministic absence case. It is useful for validating a downstream pipeline that must accept no_updates without a paid model.
The row must have found false, resultCount zero and an empty error. It cannot stand in for a real-source happy acceptance run.
Budget reference for this configuration: at most 6 payable units under the result limit, or $0.017 in planned start-plus-result events if that many complete units are delivered. This is a ceiling calculation for the configured limit, not a forecast of source yield.
Recorded platform runs (accepted acceptance runs)
The records below are exact; only checkedAt differs between repeated runs.
Happy path
Run gLkOVopetKp52AK7h on build 0.1.3, 2026-09-06, 9 s, Dataset records: 2, charged events: {"apify-actor-start": 1, "result-found": 1}. The exact first paid record is shown in the Output section above.
Input:
Correct empty-input record
Run r89NponQRJgXtNW8Z on build 0.1.3, 2026-09-06, 4 s, Dataset records: 1, charged events: {"apify-actor-start": 1, "result-found": 0}.
Source failure
The source of this Actor cannot be forced to fail from the platform; the source-failure path is proven by the fixture test recorded in proofs/source-failure.json (HTTP 503 → free partial record).
prefill (three organizations)
Run 7N2lOpiJObM10Irxn on build 0.1.3, 2026-09-06, 15 s, Dataset records: 6, charged events: {"apify-actor-start": 1, "result-found": 5}. 5 paid record(s).
Input:
First paid Dataset record (exact):
Reading a run before using its data
Open both the dataset and the OUTPUT record. They answer different questions. The dataset contains observations and explanations that can be inspected one row at a time. OUTPUT records how much work was requested, processed, delivered, charged, left unfinished, or affected by a failure. A nonempty dataset is not a promise that every supplied input succeeded. Keep the run identifier next to exports so that an individual row can be traced back to the run that produced it.
For business use, begin with found === true, partial === false, error === "" and resultCount === 1. Those fields form the complete-result contract. A row that has useful-looking source values but also partial:true is supporting evidence for investigation. It must not silently enter the same downstream table as a complete result. If you need a single export, keep the flags as columns and use a saved filter; do not discard the flags during CSV conversion.
An empty string in error has a specific meaning: the actor did not record an error for that row. It is different from an absent field, a null source measurement, an empty array of discoveries, and a run that stopped before it reached the source. A successful absence carries found:false, resultCount:0, and error:"". An unavailable source carries a reason and partial status. This distinction allows an alerting system to separate “nothing to report” from “the check needs attention.”
checkedAt is the time the actor assembled the observation. It does not replace the source's own date, establish when a model was marketed, establish when a journalist first published a story, or establish the age of a phone number. Preserve original source dates in their own columns. When comparing runs, use UTC timestamps or convert both sides to the same timezone before applying a business-day grouping.
confidence is a categorical description of the evidence boundary. It is not a calibrated probability. A value such as source_metadata means that a complete contract was assembled from the permitted source surface. It cannot be interpreted as a percentage likelihood of legal permission, business relevance, future reachability, caller identity, or an upstream provider's continued availability.
warnings can coexist with a complete result when the warning describes interpretation rather than a missing required observation. For example, catalog uncertainty is different from a failed robots request. Read warning values together with the actor-specific contract below. A partial row is always free of the result event, even when its content contains details that would have been useful in a successful check.
Delivery, budget and replay
The actor uses one result event, result-found, for each complete payable unit. The dataset row and result event are delivered through the SDK's atomic pushData interface. There is no separate application-level charge followed by an unrelated dataset write. Free explanation rows use the same dataset without a result event name. The platform's automatic run-start event is outside those row decisions.
Before a payable row is delivered, the actor reads the active pricing information and the buyer's remaining run budget. Paid deliveries are serialized through a mutex so that two callers cannot both spend the same remainder. The final comparison is made inside that critical section at microdollar precision. If the remainder cannot pay for the complete event, delivery stops and the remaining work is identified in OUTPUT when known.
An unknown budget is not treated as an unlimited budget. If the charging manager cannot return a valid budget, the actor logs a stable error and fails the run. It also refuses a pricing configuration that charges for automatic dataset items: that would make ordinary free diagnostics billable. Such a pricing problem may therefore yield no dataset rows; the authoritative explanation is the failed run and log, not a paid error record.
The guard checks SDK charge confirmation only when pricing is monetized. Local development with unmonetized SDK settings can return a zero charged count by design, so that signal is not interpreted as a buyer budget failure. In a monetized run, a missing or contradictory charge confirmation is uncertain delivery. The actor stops, records deliveryUncertain, and fails rather than retrying the same paid push.
A last successful row may legitimately be delivered with the event limit reached. That row is counted before the actor stops. If your budget was intended to cover exactly a small number of results, seeing that final row and a budget-exhausted flag is consistent. Compare paid counts and unprocessed counts before assuming that an extra row was charged or a result was lost.
Do not automatically replay a failed delivery. Inspect the dataset, OUTPUT and the platform charge log first. A transport failure can happen after some of the underlying operation has already happened. This build has no exactly-once ledger or cross-run transaction coordinator. replaySafe:false is deliberate: an operator needs to reconcile uncertain delivery before deciding what to repeat.
Network boundaries and operating limits
All source requests use HTTPS to public hosts. The runtime rejects credentials embedded in URLs, fragments, nonstandard ports, private or loopback addresses, cloud metadata destinations, mapped IPv6, and prohibited platform domains. It resolves the hostname before connecting, checks every returned address, and pins the connection to the addresses that passed that check. A public-looking hostname is not enough to pass the guard.
Redirects are handled manually. Each new target must pass the URL and address checks again; applicable actor-specific origin and path restrictions are also enforced. The source reader allows at most five redirect hops. An allowed first URL does not grant permission to follow an arbitrary redirect, carry a credential to a new host, or load a login page. The BYOK provider transport refuses redirects entirely.
The source reader has a twenty-second ceiling covering DNS, connection and body reading. API, feed and HTML responses are limited to 2 MiB each, robots to 512 KiB and llms to 256 KiB. The run also has a 50 MiB response-byte ceiling and a working deadline of 240 seconds inside the 300-second platform timeout. These limits are ceilings, not targets and not an assurance that a remote site will respond quickly.
Retries apply to transient network failures, HTTP 429 and server errors. Invalid JSON, bad XML, an unsuitable content type, a blocked destination, a refused redirect or a truncated body is not made trustworthy by repeating it. Retry-After is bounded by the working deadline. Every source attempt remains subject to the actor's run-wide request ceiling.
The actor treats returned text as data. It does not run page JavaScript, execute code from repositories, load image resources, submit a form, log into an account, open a messaging application or dereference a social link found in a source. XML external entities and DTDs are rejected by the feed reader. These boundaries reduce the surface of the job and keep the output tied to the advertised source surface.
Source availability can vary by geography, hosting network and time. A fixture test proves code behavior for the recorded response shape; it does not prove that every production host is reachable today. The accepted planning evidence includes separate datacenter observations. Cloud acceptance of this draft is a separate step and should be recorded with the actual run ID after the orchestrator performs it.
Export and integration notes
JSON is the best first export because it preserves nulls, booleans, arrays and nested evidence objects. CSV and Excel are useful for reviewing scalar fields, but nested arrays may appear as serialized JSON. Keep the JSON export if you intend to build a normalized relational table. A blank spreadsheet cell can lose the distinction between an unknown value and a deliberately empty string.
When flattening results, use the row's stable domain key and the run identifier together. Child objects such as evidence fragments or matrix cells belong to that parent result. Avoid turning each child into a separately billable unit in your own reports unless that is a clearly documented downstream convention. The actor's billing unit is defined in the Pricing section and does not change when you reshape its JSON.
A scheduled run can be connected to a dataset export, an API consumer or your own webhook integration through Apify's normal platform features. This actor does not itself create schedules, send messages, change a remote website, publish a listing or update a CRM. Test your downstream transformation against complete, absence and partial rows before attaching it to an unattended business workflow.
Use a small scope first and inspect its output. Increase one limit at a time so that changes in coverage have an explanation. A larger input array can increase request work even when the payable-result cap is small. Review both the actor-specific source ceiling and the budget ceiling, because they protect different things. A budget limits paid delivery; it does not replace a source rate or response-size limit.
Troubleshooting by evidence
The run succeeded but returned an error row. A handled source problem is represented as free diagnostic data so that the daily check stays inspectable. Read partial, error, warnings and OUTPUT rather than relying on run status alone. The run is failed when the actor cannot safely reason about money or persistent state; ordinary source failures can be contained and reported without failing unrelated complete work.
A source is reachable in a browser but the actor returns partial. Inspect whether the browser used an existing session, executed JavaScript, followed a cross-origin redirect or displayed an HTML challenge. The actor uses the documented unauthenticated source surface and validates the response type. A browser screenshot of a useful page does not show that the same permitted machine-readable response was available to the actor.
Fewer paid rows appeared than the requested maximum. The maximum is a ceiling. Filtering, deduplication, absence, unknown source data, the working deadline, a source cap or a buyer budget can all reduce delivered complete rows. OUTPUT identifies measurable unprocessed work; source pagination may also leave an uncounted tail that is reported as a cap warning rather than an invented exact count.
A field contains null. Read the field's definition before substituting zero. Null preserves lack of evidence. Zero is a measurement or count and can materially alter a chart, a score or an automated decision. If your destination system cannot represent null, keep a companion status column that explains the substitution. Do not silently transform unknown observations into favorable outcomes.
A source changed its response structure. Keep the relevant source URL, run ID, actor version, status flags and a minimal redacted excerpt when opening an issue. A useful bug report explains which expected field was missing and how the row was classified. Do not include API keys, private account information or unnecessary personal contact details in a public issue.
Can the build be treated as cloud accepted? The private build named in the evidence banner passed the acceptance runs listed under Recorded platform runs; publication to the Store is a separate step.
Support and responsibility
Use the actor's issue page for a reproducible defect or a request for a new response shape. Include the input settings with secrets removed, the run ID where available, the affected field and whether the problem is complete absence, partial source failure or uncertain delivery. A short reproducible example is more useful than an unfiltered export containing unrelated data.
The buyer supplies the scope and must have an appropriate basis for processing and retaining it. Public reachability and a robots rule are different from permission to republish content or contact a person. Apply your organization's retention, access and data-protection rules, including applicable PIPL and GDPR obligations where relevant. This tool reports technical evidence within its contract; it does not issue a legal clearance.
Compact Chinese guide / 中文说明
本工具仅处理输入中指定的公开来源，输出包含完整结果、无结果和部分失败三种不同情况。请同时查看 found、partial、error 和 OUTPUT，不要把未知值 null 改成零或百分之百。完整结果按 result-found 事件计费，错误和说明行不收取结果事件费；启动费仍可能产生。
模型仅来自元数据接口，不下载权重或代码。首次基线没有历史速度；下载指标变化可以为负数。ModelScope 请求失败不会覆盖成功基线。
Related tools
Related tools for adjacent workflows in data pipelines for AI applications.
| Actor | What it does |
|---|---|
| URL to Markdown Converter | Pair it in the data pipelines for AI applications workflow: Convert up to 100 authorized public HTML pages into clean Markdown for RAG, AI agents, SEO research, and... |
| Live Price Oracle | Pair it in the data pipelines for AI applications workflow: Get timestamped DexScreener market observations for up to 100 token contracts or bounded ticker searches |
| RAG Dataset Builder | Pair it in the data pipelines for AI applications workflow: Turn buyer-authorized public website sitemaps into bounded, source-linked text chunks for RAG, search,... |
| Structured Data Extractor | Pair it in the data pipelines for AI applications workflow: Extract title, meta, JSON-LD, headings, links, emails, and price observations from up to 100 authorized... |
