Wikipedia Article and Table Data Extractor
Pricing
from $1.40 / 1,000 articles
Wikipedia Article and Table Data Extractor
Extract English Wikipedia article text and wikitable data into one attributed JSON record, with HTML revision evidence and explicit free truncation notices.
Pricing
from $1.40 / 1,000 articles
Rating
0.0
(0)
Developer
Tim Zinin
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
2 days ago
Last modified
Categories
Share
Extract English Wikipedia article text and wikitable data into one attributed JSON record, with HTML revision evidence and explicit free truncation notices.
Evidence status (2026-09-05). The actor was built on the Apify platform (build mBkKtc51HiLYnlQsg), its pay-per-event tariff was read back from the platform, and three private acceptance runs on Apify infrastructure produced the rows shown in this document: a complete article, a clean 404 and a capped free partial. Two independent review rounds preceded the build.
R1. What you get
The output combines article prose, section headings, rectangular data tables and provenance in one dataset row per complete article. You can keep text, tables or both. Data tables are selected by Wikipedia’s wikitable class; menus, layout tables and infoboxes are outside this projection.
The actor reads article HTML on English Wikipedia. It does not query /w/, /api/ or a REST endpoint, download media, crawl linked articles or search Wikipedia for you. The article URL is the boundary of the requested work. HTML configuration can provide a revision ID without an additional source request.
R2. Who uses it
Researchers use the result to attach a reproducible source record to a reference table. Analysts can inspect a short table before moving it into a warehouse. Editors can preserve the article link and transformation notice alongside an extract. A team that needs a whole-language Wikipedia dump, live edits or entity resolution needs a different source contract.
The most useful first inputs are articles whose tables you have already inspected. The prefill about permanent members of the UN Security Council contains two ordinary wikitables within the default caps. The population-by-country list contains 239 data rows in the observed HTML and deliberately exercises truncation; increasing the input cap to the maximum 200 still does not make that article complete.
R3. How to run
Paste one English /wiki/ article URL, select text and tables, and leave the defaults for the first run. Inspect the title, revisionId, table count and licenseUrl before using the values. If your task only needs prose, set includeTables=false explicitly so an irrelevant large table does not make the selected article extraction partial.
Start with one source and a small result limit. Run it once, inspect both the dataset and the OUTPUT summary, and save the input next to the run ID. This gives your team a reproducible baseline before a recurring schedule starts. A successful platform status means execution finished; it does not by itself establish that a useful result was obtained. Check found, resultCount, partial and error in the actual rows.
Use the dataset preview to inspect nested values before exporting to a spreadsheet. JSON preserves arrays, nulls and booleans most faithfully. CSV is a presentation format: arrays may appear as serialized values and spreadsheet applications can reinterpret strings. Download a JSON copy when you need an audit record. Keep the source URL and checkedAt value attached to every derived row so a colleague can identify the observation behind a decision.
After that first inspection, connect the run to an existing Apify schedule or your own workflow. Choose a frequency that matches how often the source changes. Scheduling faster than the publisher updates usually adds cost without adding evidence. A schedule is a series of independent runs, each with its own input, resource limits and start event. The actor does not create schedules, send messages or modify the source on your behalf.
Before handing the workflow to someone else, document the expected paid unit, the chosen caps and the action for an empty or partial response. Give the receiving team one successful dataset example and one free failure example from your accepted runs. Do not teach an integration to treat every dataset row as a billable result: explanatory rows deliberately share the same dataset so they remain visible during export.
R4. Pricing
A table is not a separate paid unit. Five tables from one complete article cost one article event. Conversely, a useful table preview from a truncated article gets no result event. This keeps the pricing unit aligned with the promised article-level completeness contract.
The price is $0.003 per start + $0.002 per article, read back from the platform tariff on 2026-09-05 (apify-actor-start $0.003, result-found $0.002, model PAY_PER_EVENT). The primary paid unit is one complete article extraction under the selected text and table settings. A truncated article is free, even if its visible preview contains useful cells. The start event is charged once per GB of run memory: the default 512 MB run pays one start unit, while the acceptance runs below were started with 4096 MB and therefore show apify-actor-start: 4 in their charged event counts. Keep the default memory unless an article needs more.
| Completed paid units | Proposed total including one start |
|---|---|
| 0 | $0.0030 |
| 1 | $0.0050 |
| 5 | $0.0130 |
| 20 | $0.0430 |
| 100 | $0.2030 |
These are arithmetic examples at the tariff above, not receipts. Input and response limits can require multiple runs; each additional run has its own start. Free result rows do not refund a start event that has already occurred.
Billing follows delivery of the documented unit. One completed article is written with the named result-found event in the same SDK call. An incomplete unit or diagnostic notice is written without that event. The distinction is visible in found and resultCount; the OUTPUT summary separately reports delivered, paid and free. A dataset can therefore contain more rows than the number of paid results. Count result events when reconciling invoices.
The actor reads the actual run pricing before source work. On the platform, a missing result price, unreadable pricing or a priced automatic dataset-item event stops the run. If writing an explanation might itself cost money, the explanation stays in the log and failed run status. The start event may already have been charged. A failed run is not a promise that every previous activity was free, so reconcile the recorded event counts rather than assuming a refund.
A budget check runs inside the same lock as the paid write. Concurrent delivery attempts cannot both reserve the same last available amount. The check compares remaining money with the next row price before calling the SDK. This guards against the SDK behavior that can otherwise permit one final row beyond the limit. A budget just below one complete unit produces zero additional paid rows; it is not rounded up to buy a unit the budget does not cover.
If the SDK says the last paid row reached the event limit, that row still counts as delivered and paid. Only subsequent work stops. If delivery or charging throws, the outcome can be uncertain: a dataset write may have succeeded before a charge response failed. The actor stops and marks the run failed instead of automatically retrying the row. Reconcile the dataset and event counters before rerunning an uncertain delivery, because a new run can repeat previously obtained data.
Platform evidence for the tariff above: run U9ksFCKaePbC9wNmz (complete article) charged result-found: 1; run d1hIneluf6npvXHgg (404) and run K6zN1imJ7nzgBosox (capped partial) charged result-found: 0. Each of the three runs also charged the start event according to its memory. Platform account subscriptions, prepaid credits and discounts are governed by the account's current terms.
R5. Input contract
All article URLs must remain on en.wikipedia.org with a normal /wiki/ path and no query parameters. Namespace routes containing a colon are refused, including Special:, File:, Category: and Talk:. Fragment identifiers are normalized away because they do not change the fetched document. The prefill is a real live article, not a synthetic fixture.
articleUrls
English Wikipedia articles only. The prefill has two verified data tables with 5 and 19 rows. This avoids the 239-row population table exceeding the maximum 200 rows per table.
Type: array. Default/prefill: ["https://en.wikipedia.org/wiki/Permanent_members_of_the_United_Nations_Security_Council"]. Declared constraints: {"maxItems": 10}. The runtime validates this field before starting source work; invalid values produce a failed run through the free log/status channel. Numeric strings and truthy strings are not silently accepted as numbers or booleans.
includeText
Include normalized article prose and heading metadata. Table text, navigation, scripts and reference lists are removed from prose.
Type: boolean. Default/prefill: true. Declared constraints: {}. The runtime validates this field before starting source work; invalid values produce a failed run through the free log/status channel. Numeric strings and truthy strings are not silently accepted as numbers or booleans.
includeTables
Extract table.wikitable elements outside navigation or nested tables. Layout and infobox tables are excluded.
Type: boolean. Default/prefill: true. Declared constraints: {}. The runtime validates this field before starting source work; invalid values produce a failed run through the free log/status channel. Numeric strings and truthy strings are not silently accepted as numbers or booleans.
maxTables
Maximum selected data tables per article. Exceeding this cap creates an incomplete free article. Zero omits available tables with partial=true when table extraction is selected.
Type: integer. Default/prefill: 10. Declared constraints: {"minimum": 0, "maximum": 20}. The runtime validates this field before starting source work; invalid values produce a failed run through the free log/status channel. Numeric strings and truthy strings are not silently accepted as numbers or booleans.
maxRowsPerTable
Maximum data rows after leading all-header rows. Up to 200, with article count × table cap × row cap <=10000.
Type: integer. Default/prefill: 100. Declared constraints: {"minimum": 1, "maximum": 200}. The runtime validates this field before starting source work; invalid values produce a failed run through the free log/status channel. Numeric strings and truthy strings are not silently accepted as numbers or booleans.
Send one JSON object as input. Arrays are bounded before work starts, and the implementation rejects unknown input fields rather than silently ignoring a misspelled option. Use JSON booleans true and false, not the strings "true" or "false". Use integer values for limits. Limits are ceilings, not promises that the source contains that many useful records. A valid request can return fewer records or a free status row.
URL inputs are limited to 2048 characters and HTTP or HTTPS. Credentials in a URL are rejected. The actor does not forward your browser cookies, use an authenticated session, read local files or interpret source text as instructions. A publicly routable address still has to match the reviewed source scope. Adding an unreviewed URL to input does not extend the actor's rights or capabilities. Requests and redirects stay subject to the same source and network checks.
The caps work together. Increasing a per-source limit does not override the run deadline, byte limit, maximum number of input sources or output-size limits. Split a large job into bounded runs and record which inputs belong to each batch. If you change a limit between runs, preserve that change in your evidence log: two outputs collected under different truncation settings are not directly comparable without checking partial flags.
Defaults are intended to make a small first run inspectable. They are not a production source recommendation or a guarantee of permanent availability. A source owner can move content, change markup or temporarily reject requests. Keep your selected production input in a saved task after acceptance so an updated default does not silently change what your schedule monitors. Recheck permissions and source scope whenever the production URL changes.
R6. Output examples and result states
A complete article has status=ok, found=true and resultCount=1. A missing article with HTTP 404 has status=not_found, found=false, resultCount=0 and error="". A disambiguation page, which only lists possible meanings, is also a free not_found row with a warning naming the reason; pick one of the linked article titles instead. A larger table under maxRowsPerTable=1 yields status=partial, found=false and resultCount=0 while retaining a bounded preview.
An HTML page containing a menu but no recognized article-content root is a source_error. It is not sold as an article. The rows in this section are unedited output of the accepted platform runs named below.
A row with found=true and resultCount=1 represents the actor's documented completed unit. A row with found=false and resultCount=0 needs its status interpreted. Clean absence has an empty error string; transport, parsing and delivery problems carry a nonempty error or fatal run summary. Do not collapse these cases into a single empty-table branch. They answer different operational questions and require different follow-up actions.
The partial flag describes completeness under the selected input and caps. It can appear on a free notice after complete units have already been delivered, or on an incomplete unit that is not billable. The per-product rules in this section tell you which case applies. A downstream workflow should preserve the flag even when it keeps the useful data. Removing the warning during CSV flattening can turn an honest limited observation into an unsupported claim of completeness.
The default key-value store record OUTPUT is the run summary. Requested describes the input scope; processed describes units or inputs examined according to this actor's documented counter; unprocessed identifies remaining work. Delivered and paid describe successful result delivery, free describes explanatory rows, failed counts delivered error notices, and deliveryUncertain identifies writes that require reconciliation. These counts are not interchangeable with HTTP request count.
The examples below are dataset rows from private acceptance runs executed on Apify infrastructure on 2026-09-05 with the deployed build and the live tariff. Long fields are shortened for display only, and every shortening is marked inside the value; the run datasets hold the full rows.
Accepted platform run examples (2026-09-05)
Example A is the complete paid article from run U9ksFCKaePbC9wNmz (default input: the prefill article, text and tables on). Example B is the clean 404 from run d1hIneluf6npvXHgg. Example C is the free capped partial from run K6zN1imJ7nzgBosox with maxRowsPerTable=1. Cells keep \n between the lines of one cell, as R7 promises.
Example A — complete article, paid (result-found: 1). The text field and long tables are shortened for display; the shortening marker is part of the display only.
Example B — missing article, free (result-found: 0).
Example C — capped article under maxRowsPerTable=1, free partial (result-found: 0). Shortened for display in the same way.
R7. Field dictionary
input
Original normalized requested article URL. Use this to join back to your input batch. An article redirect or canonical declaration does not overwrite which input you requested.
sourceUrl
Requested article URL retained as request provenance. canonicalUrl records the article canonical location when its declaration passes the same article scope. No /w/ or /api/ route is requested.
found
True only when useful requested article content was extracted completely within every configured cap. A partial preview remains false and is not a billable article.
status
ok is a complete extraction; not_found is clean absence; partial identifies cap-limited content; source_error identifies a failed fetch or missing article-content structure. Evaluate error alongside this value.
resultCount
One for a complete paid article; zero for a free diagnostic or incomplete article. It is not the number of extracted tables, sections, sentences or rows.
partial
True if any selected extraction cap cut content, including table count, table row count, expanded cell bounds, text length, section count or serialized output size. No incomplete article gets a result event.
error
Empty for clean absence and ordinary cap truncation. Nonempty for source errors and the output-size cap. Empty is not equivalent to absent, null or false in acceptance checks.
warnings
Human-readable extraction caveats. Missing HTML revision evidence and unavailable recognized license links are reported here. The array may also explain a cap without converting it into a transport failure.
checkedAt
UTC timestamp of extraction observation. This is not the article revision date or the date of every fact mentioned in the prose. Keep it separate from revisionId.
schemaVersion
Version 1.0 of the row contract. Store it with exports if a downstream pipeline depends on the current names, null behavior or table projection.
title
Visible article heading from #firstHeading. The title can differ from the requested URL because Wikipedia maintains article redirects and titles can change.
canonicalUrl
Allowed article canonical link if supplied in the HTML, otherwise the requested URL. This is suitable for linking readers back to the article. A forbidden canonical value is ignored without requesting it.
revisionId
Safe integer read only from a wgRevisionId literal in an HTML configuration script using mw.config or RLCONF. Null means no reliable literal was found. The actor never evaluates the script or calls the API to fill this gap.
text
Normalized selected prose, limited to 200000 characters. Paragraphs, lists and headings remain in document order. Whitespace is collapsed within segments, with newlines between them. References and navigation are not included in this text projection.
sections
Up to 300 h2–h4 headings with title, numeric level and available HTML id. These describe the extracted document structure; they are not independent paid records or a semantic classification of its subject matter.
tables
Array of selected wikitable objects. Each has caption, headers, rows, partial, sourceRowCount and headerRowCount. Cells are strings, leading header rows are combined by column, and colspan/rowspan values are repeated into a rectangular grid. Line breaks and list items inside one cell are kept as \n inside the string, so two names or two values in one cell never fuse into one word. Footnote markers such as [3] or [c] are removed from cell values.
licenseUrl
Recognized CC BY-SA URL from the response link or anchor, or null if unavailable. The actor preserves evidence rather than assuming a license URL that was not present in the HTML.
licenseUrls
Distinct license links observed in the document. Additional notices can affect particular content. Use these links with notices when assessing redistribution of a derived table or text extract.
attributionUrl
Canonical article URL for attribution. Keep it with any copied table or prose and indicate your transformations. A URL alone may not satisfy every attribution requirement for every reuse.
notices
Visible footer copyright notice, bounded to 10000 characters. If the served HTML lacks this footer, the value can be empty. The license link and original article remain the places to inspect additional conditions.
modifications
Description of the mechanical transformations applied: normalization, table grid expansion and navigation/reference removal. Supplement it with your own transformations when you publish a derived dataset.
R8. Evidence and boundaries
The local source review on 2026-09-05 obtained HTTP 200 for both the permanent-members article and the population list. Their HTML contained wikitable elements and wgRevisionId configuration literals. The observed permanent-members revision was 1372169675; live acceptance must not freeze that mutable ID as a permanent expected value.
Wikimedia article reuse is governed by its applicable terms and licenses. This actor keeps article URLs, license links and a transformation description together. A machine conversion does not establish that a scientific or political statement in the article is accurate.
Every observation is tied to the response actually obtained. checkedAt is the actor's collection time; it does not automatically mean that the source data was published or updated at that time. Cached pages and feeds can be older than their HTTP response time. Source dates, revisions and validators should remain separate fields in your downstream model. If a publisher omits a field, absence is preserved rather than replaced with a plausible value.
The HTTP transport validates the URL before connection, checks every DNS answer, rejects private and loopback addresses and pins the approved address to the connection. Redirects are checked again, including redirects that appear to remain on the same host. These safeguards apply to robots requests as well as content requests. A redirect into a forbidden host or route stops that request; the actor does not follow it because the first URL looked acceptable.
Responses are bounded in bytes and time. At most five redirects are followed per attempt. Network failures, 429 and server errors can receive at most two retries with bounded backoff; Retry-After is considered within the remaining deadline. Ordinary client errors and invalid successful-response formats are not retried as if waiting would repair them. A timeout describes what the actor observed; it does not prove that the source is permanently unavailable.
The reviewed route scope and robots checks are operational constraints, not a universal rights classifier. A robots allow rule is not a copyright license, and a public URL is not proof that every possible use is authorized. The actor keeps its source-specific scope deliberately narrow. When you need a new source, provide the exact URL, its owner or license basis and a representative response for review. Source availability and permission are separate acceptance questions.
Exported text remains untrusted source data. The parser does not execute scripts or follow instructions embedded in content. If you later send the text to an AI workflow, place it in a data field and give that workflow its own instruction boundary. Do not let a publisher-controlled title, description or table cell choose credentials, network destinations or workflow permissions.
R9. Decision routing
Route complete articles to a staging dataset. Route partial articles to a table-size or text-cap review without charging an article event. Route a clean 404 to a missing-source queue; route a timeout or content-structure error to a source-health queue. A moved or renamed article should be inspected through canonicalUrl before declaring the original source gone.
Create explicit routing branches for complete results, clean absence, partial observations, source errors and fatal delivery problems. The normal success branch should require the documented completed-unit fields, not merely a nonempty dataset. The absence branch can record that no matching content was observed. The partial branch should retain useful complete units while opening a review item for the missing scope. The error branch should avoid overwriting the last good source record with an empty value.
Use a small retry policy in the surrounding workflow. The actor already retries suitable transient HTTP failures. Immediately restarting the entire run several times can multiply start charges and repeat already delivered units. A delayed retry with the same saved input is easier to reconcile. If the run reports delivery uncertainty, compare the dataset and result event counts first; an automatic full retry is especially inappropriate when the previous write may have landed.
Keep decisions proportional to evidence. A machine-readable status is suitable for triage, a review queue or a candidate change list. It is not a substitute for inspecting the underlying source before a consequential decision. Attach the source URL, collection time and relevant evidence fields to any ticket or report your workflow creates. That lets an operator verify the observation without rerunning the entire extraction.
When the result changes between runs, compare the same source identity and the same input limits. A different cap, redirect destination or source revision can explain the difference. Do not label a missing row as a deletion until you have ruled out partial output, a changed source scope and a failed request. Preserve the last successful observation alongside the latest attempt so outages do not look like intentional content removal.
R10. Commercial playbooks
For a reference-table import, retain a parent article record keyed by canonical URL and revision ID when available. Flatten each table into child rows with table index and row index. Keep the original headers and caption on the table record. This preserves the distinction between two tables that happen to use the same column label.
For editorial reuse, attach the attribution URL and license evidence to the export. Record any subsequent sorting, numerical conversion or cell edits. The actor deliberately leaves values as strings so a dash, footnote marker or percentage is not silently converted into a number.
For a recurring operational report, start by defining the question the report must answer and the smallest source set that can answer it. Store each run's input, summary and result dataset together. Produce a compact review view for colleagues, while retaining the original JSON for audit. This creates a traceable chain from a source observation to a business action without pretending that extraction alone proves the action was correct.
For a client deliverable, agree on the unit, source scope and completeness rules before collection. Explain whether a capped response is acceptable and who reviews failures. Quote the proposed extraction cost separately from your own analysis and service fee. A small technical result can still require editorial or operational judgment, and the actor does not promise revenue, savings or a particular conversion rate from that judgment.
For a migration or recurring comparison, freeze the input configuration for the comparison period. Assign a batch identifier in your own workflow and save a baseline dataset. Run the same source scope again after the change, then compare stable identities and evidence rather than dataset row positions. Row order is useful for inspection but is generally a poor business key. Mark differences whose underlying run was partial as requiring review.
For an internal acceptance checklist, have someone other than the builder inspect a successful result and a deliberate negative. Verify source identity, the paid-unit count and how the integration handles a free notice. A positive demo alone does not exercise the branches most likely to cause misleading dashboards. Keep this check small enough to repeat when the actor version, source markup or saved input changes.
R11. Integration recipes
Flatten a table with an article key, table index, source row position and one field per header position. Duplicate header names can occur; use column position as the technical key and the header as its display label. Multi-level headers are joined with " / ", and merged cells are expanded by repetition. Keep that transformation visible to analysts.
Dataset API and typed storage
Use the dataset identifier from the completed run when fetching results. Store the original JSON response before projecting columns into your application database. Preserve booleans as booleans, null as null and arrays as arrays; stringifying everything makes later validation harder. If your warehouse needs flat tables, create parent and child records with an explicit parent key and retain the source URL on the parent.
n8n or Make
Create a workflow that starts the saved task, waits for the run to finish, reads the summary and then downloads the dataset. Put the summary-status branch before the action that updates production records. Route partial and fatal runs to a review path. Avoid treating "run finished" as "all expected data arrived". Keep any credentials in the workflow platform's secret storage rather than placing them in source URLs or exported dataset columns.
Webhook receiver
A completion notification is a signal to fetch the run artifacts. It is not a complete substitute for those artifacts. Make your receiver idempotent using the run identifier and your own processing ledger, because webhooks can be delivered more than once. Acknowledge the notification promptly and process large exports separately. This prevents a slow database transaction from causing repeated notifications and duplicate downstream actions.
Spreadsheet review
Choose a stable set of top-level columns and keep a separate JSON archive for nested fields. Add a visible status or partial column next to the business content rather than hiding warnings on another sheet. When opening CSV in spreadsheet software, import identifiers and source text as text where appropriate. Spreadsheet auto-formatting can alter leading zeros, dates and strings beginning with formula characters. That is a downstream import concern, not evidence that the source changed.
Application database
Use a staging table before merging into a canonical dataset. Validate expected types, source identity and completed-unit status in staging. Keep a record of the input settings and actor version with the batch. Commit the merge only after your chosen completeness checks pass. An empty or failed extraction should create an attempt record without deleting the last known good data. This pattern makes source outages visible while protecting previously reviewed information.
Human review queue
Create one review record per actionable observation and include the original source URL, collection time, reason and relevant evidence. Group related observations in your own application rather than dropping provenance to reduce row count. The actor supplies evidence; your integration decides who receives it. It does not send emails, create tickets or message third parties by itself.
Reproducible exports
Save the input JSON, run ID, default dataset ID and OUTPUT summary together with your export. If a recipient asks why a value was included, you can reconstruct the observation without guessing which run produced the file. When you transform text or flatten nested data, document the transformation in your own export metadata. A derived CSV should not be presented as an untouched source response.
R12. Operating guide
The row grid permits at most 100 columns, rowspan up to 200 and cell text up to 20000 characters. Invalid, overlapping or excessive spans mark the article partial. Nested tables are not recursively sold as additional article tables. Very large HTML is refused before parsing at 2 MB; the serialized article row cannot exceed 5 MB.
There is no cross-run ledger. Repeating a completed article extraction can produce and charge the same revision again. Use your own dataset key if your downstream warehouse needs one copy per revision, while retaining separate run records for collection history.
Resource envelope
The deployment defaults to a 300-second run timeout and a shorter 240-second working deadline. Per-response byte caps, input caps and request ceilings provide additional bounds. The shorter deadline leaves time to stop source work and write a summary before the platform timeout. It cannot guarantee recovery from every external failure, such as a storage service that remains unavailable during finalization.
Requests are paced per host. The one-request-per-second setting is this actor's own conservative operating limit, not a claim about an upstream service's published quota. Redirects, robots reads and retries consume requests too. Increasing the number of sources can therefore increase elapsed time even when few paid units result. Do not estimate runtime solely from the number of dataset rows.
Read the summary first
Compare requested, processed and unprocessed to understand how much of the input was handled. Then compare delivered and paid with result events, and inspect free and failed for diagnostic rows. HTTP request count measures transport activity, not billable output. A batch can require several requests for a single unit, and a free source failure still consumes bounded runtime. Preserve these counter meanings in dashboards and support tickets.
Change management
Recheck your saved task after an actor version change or a source format change. Run the smallest representative input, inspect the typed output and compare the paid unit count with expectations. If your application depends on a nested field, test that field specifically rather than only checking that a dataset exists. Keep the previous accepted export so you can distinguish a parser regression from a real upstream content change.
Reconciliation
When delivery is uncertain, record the run ID before doing anything else. Download the dataset and inspect chargedEventCounts from the run. Compare the results with the OUTPUT counters and log messages. The actor does not claim a transaction spanning external storage, a charge service and your downstream database. A failed charge response can leave useful data present, so never infer non-delivery from a failed run status alone.
Troubleshooting workflow
Start with the exact input that failed, the run summary and one affected source URL. Check whether the failure was input validation, source-scope refusal, robots refusal, DNS or transport failure, response format, a resource cap or delivery. Change one factor at a time and rerun a small bounded case. Removing all caps or broadening the source scope to chase a single failure usually obscures the reason rather than resolving it.
Acceptance and release
Local tests exercise the actual Apify SDK charging path with controlled persistence and charge transport boundaries. They cover exact budget boundaries, concurrency, missing pricing, priced dataset writes and failures before and after dataset delivery. They are necessary implementation evidence but do not replace a private platform build, real source canary, tariff readback or independent acceptance. The build draft remains a draft until those separate checks are recorded.
R13. FAQ and limitations
Why are numeric cells strings? Wikipedia tables mix units, notes, separators and missing-value markers. Keeping strings preserves the observed representation. Apply a domain-specific conversion after inspecting the header and footnotes.
Why is revisionId null? The served HTML did not provide a reliable configuration literal. The actor intentionally performs no API or /w/ request to repair it.
Why is an apparently useful article free and partial? At least one selected extraction cap was reached. Adjust the selected scope or accept the bounded preview as incomplete.
Why does the dataset contain a row with no business content? The actor returns free status rows to distinguish clean absence, limits and errors. Those rows keep the reason visible in the same export. Filter on the documented completed-unit contract when calculating useful output, and retain status rows in an operational log so the integration does not hide failures.
Can I remove every limit for a large job? No. The actor has a bounded product contract, including runtime, input and response limits. Break larger jobs into reviewed batches. A source that needs a browser, authentication or a different endpoint requires a separate capability decision rather than an unlimited flag.
Does a public URL establish permission? No. Accessibility, robots rules, copyright licenses and your intended use are separate questions. The supported scope is documented below. If you need another route, request a source review with specific ownership or license evidence. The actor does not infer permission from a checkbox.
Will a retry produce exactly the same output? Only if the source and relevant state remain unchanged and the same limits are used. Live content can change between attempts. Keep source identities, revisions or hashes where available and retain the input. Do not promise byte-identical exports from a changing external source.
What should I send in a bug report? Include the actor version or build ID, run ID, a minimal redacted input, the expected contract and the actual status or field. Remove tokens and confidential source content. One representative row plus the summary is usually more useful than a large unfiltered export. Explain whether the issue reproduces in a fresh small run.
Is this page a guarantee of platform cost or availability? No. The prices above were read back from the deployed tariff on 2026-09-05; check the tariff shown on the Store page before a large run. The source can change independently of the actor. Local parser and SDK tests establish specific behavior under tested conditions; cloud acceptance and ongoing operational monitoring establish different facts.
R14. Sources, rights and support
Primary references: Wikimedia Terms of Use, English Wikipedia robots rules, and the article’s own license and attribution links. Cheerio loading documentation describes the inert HTML parser used here. Sources are read as data; embedded scripts are never evaluated.
Use only sources and content that you are authorized to process for your intended purpose. Preserve publisher attribution and applicable license notices in derived work. A conversion to JSON does not remove the obligations attached to the original content. Where the source has additional notices, keep those notices with the evidence and review them before redistribution.
The actor fetches the bounded source material described in its contract. It does not grant permission to redistribute an entire third-party archive or expand into neighboring endpoints. If your source redirects outside the reviewed scope, the correct response is to review the destination; the actor does not automatically treat that destination as authorized. Changes to source terms or access rules may require an updated scope review.
For support, use the issue channel on the actor's Apify page after publication and include a reproducible minimal case. Deployment-specific evidence should include the build ID and run ID so support can compare the code and pricing used by that run. Never include API tokens, private cookies or unrelated personal data in a public issue. For a new capability, describe the input source, expected unit and the decision your integration needs to make.
Related-tool links below point only to published actors of the same author. The output examples above are accepted platform rows, not screenshots of local fixtures.
Related tools
Related tools for adjacent workflows in data pipelines for AI applications.
| Actor | What it does |
|---|---|
| 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... |
| 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,... |
| 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... |
