# Chronometrica vs Apidojo Tweet Scraper for X Keyword and Date Research

Choose Chronometrica X Search Scraper when you need a bounded sample for each keyword query and its saved query details meet your study needs. Its checked strengths are inclusive calendar-date inputs, the exact generated query, row positions, and separate query outcomes. Choose Apidojo Tweet Scraper V2 when you need its richer author, location, media, engagement-minimum, language, or query-wizard filters. [Chronometrica documentation](https://apify.com/chronometrica/x-search-scraper) · [Apidojo documentation](https://apify.com/apidojo/tweet-scraper)

The choice starts with what you must collect. A small set of posts for review needs different controls from a request for every matching post. Both requests can use the same keywords and dates, but they require different evidence of success.

Chronometrica publishes this comparison. It uses public product evidence checked on October 20, 2026. No collection run was made for this article. The recommendation concerns the documented inputs and outputs. It does not claim a speed, cost, coverage, accuracy, or reliability advantage.

An Actor is a hosted collection program. For this comparison, the useful question is which Actor gives you the filters and records needed to accept a keyword sample from a set date range.

## Choose by the sample you must accept

A public buyer request asks for X data collected by keywords during a specific period. That supports a date-scoped collection need. It does not establish a need for a complete historical archive or an exact count of every matching post. The named product comparison here is our editorial choice. The request is not a verified product benchmark. [Public buyer request](https://www.reddit.com/r/webscraping/comments/19bekjv/is_there_a_current_solution_to_scrap_tweets)

Write a short acceptance statement before you choose an Actor. For example: “I need up to 10 dated posts for each keyword, with enough search context to check each sample.” This gives you a practical basis for the decision. You can check whether the inputs express the request and whether the outputs preserve the evidence.

| Decision point | Chronometrica X Search Scraper | Apidojo Tweet Scraper V2 |
| --- | --- | --- |
| Keyword and date search | Native inclusive calendar-date inputs | Keyword search and start/end controls |
| Checked fit | Bounded samples with explicit query records and row positions | Searches needing broader explicit filters |
| Relevant controls | 1–20 queries; 1–1,000 saved rows per query | Advanced syntax; author, media, location, engagement, language, and query-wizard filters |
| Selection rule | Choose when the sample cap and query records meet the study | Choose when those filters define the sample |

The table summarizes the checked public documentation. It does not treat an undocumented feature as absent. Keyword and date filtering are shared capabilities. [Chronometrica documentation](https://apify.com/chronometrica/x-search-scraper) · [Apidojo documentation](https://apify.com/apidojo/tweet-scraper)

Apidojo’s documented large-scale policy excludes single-tweet fetching. That limit does not change this multi-result search decision. [Apidojo documentation](https://apify.com/apidojo/tweet-scraper)

For Chronometrica, the main limit is the saved-row cap. If your requirement is every matching post and it exceeds 1,000 saved rows for any query, Chronometrica does not meet that requirement. A request below that cap still needs evidence of coverage. An allowed input size does not prove that the source will return every matching post. [Chronometrica documentation](https://apify.com/chronometrica/x-search-scraper)

## Why Chronometrica fits bounded keyword samples

Chronometrica preserves the search context for its saved rows. `inputQuery` records the supplied query. `executedQuery` records the exact generated query. `searchMode` records the selected mode. `resultPosition` records a row’s observed position within that query. These fields let you connect a saved post to the search that produced it. [Chronometrica documentation](https://apify.com/chronometrica/x-search-scraper)

That connection matters when you compare keywords. Two queries can use the same date window and row cap but return different numbers of accepted rows. Keep those outcomes separate. Otherwise, a combined export can hide which query reached its cap and which returned fewer rows.

Chronometrica also documents per-query `OUTPUT` accounting: the reported outcome for each query. Read it with the saved rows. A row file shows what you collected. The query outcome helps you assess whether that collection met your request. [Chronometrica documentation](https://apify.com/chronometrica/x-search-scraper)

Use `resultPosition` only within this context. It is an observation from one query. It is not a lasting rank, a quality score, or proof that the post represents the topic. Preserve it to review the sample order. Do not use it to measure a post’s importance. [Chronometrica documentation](https://apify.com/chronometrica/x-search-scraper)

This is a strong fit when a researcher needs a limited set of posts to read, label, or compare. The records help the researcher explain what was observed. The researcher must still decide whether those observations support the intended analysis.

## Make the date window clear before collection

Chronometrica accepts optional `startTime` and `endTime` inputs as inclusive calendar dates. Its documented route adds visible date filters and checks returned post dates again. Do not also add `since:` or `until:` operators to the same native-date request. [Chronometrica documentation](https://apify.com/chronometrica/x-search-scraper)

Inclusive dates mean that both requested calendar dates belong to the request. They do not remove the need to define your study’s timezone. A calendar date alone does not state which hours belong to a local reporting day.

Record the intended timezone before you run the search. When needed, convert the intended start and end boundaries to Coordinated Universal Time (UTC), the common time reference used to compare timestamps. Check the conversion for the dates in your study. Use those checked timestamps when you inspect returned posts.

Keep two parts of the request together: the original inclusive calendar dates and the precise timestamp window used to accept rows. This lets another reader understand both the input and your decision about whether a post belongs in the study.

Choose one date-control method for the initial check. Use native date inputs when they express your request. If you use advanced query operators instead, inspect the generated query before you accept the result. Do not combine both methods without checking how they affect that query.

For the wider date-check method, see [How to Search X Posts by Keyword and Date](/en/articles/x-date-query-design/). This comparison answers the product decision: which Actor’s filters and output records suit your collection requirement.

## Prepare a small input you can check

Chronometrica documents 1–20 queries, `latest`, `top`, `photos`, and `videos` modes, and a maximum of 1–1,000 saved rows per query. Start with a small cap that lets you inspect every saved row. [Chronometrica documentation](https://apify.com/chronometrica/x-search-scraper)

The following input requests up to 10 saved rows for one keyword during January 2026. It uses native dates and the `latest` mode.

```json
{
  "queries": [
    "artificial intelligence"
  ],
  "searchMode": "latest",
  "maxItemsPerQuery": 10,
  "startTime": "2026-01-01",
  "endTime": "2026-01-31"
}
```

Prepare a small input you can check

This input passed a local check against the cached public JSON Schema. A JSON Schema defines allowed input fields and values. All supplied field names exist in that schema. This confirms the input shape. It does not prove live source availability or promise 10 returned rows. [Chronometrica public input schema](https://apify.com/chronometrica/x-search-scraper)

The public [X Twitter Search API Dataset Task](https://apify.com/chronometrica/x-search-scraper/examples/x-twitter-search-api-dataset) provides a starting preset. A Task is a saved input preset for an Actor. The checked page returned HTTP 200, a successful page response. That check did not confirm its current saved input.

Open the Task input and apply your intended settings before any run. Replace the example keyword and dates with your study’s values. Keep the cap small for the first check. The example above is an input example, not a collected result.

## Run a five-step acceptance check

Use these steps to decide whether the chosen Actor produces a sample you can use.

1. Write the collection requirement. List the keywords, calendar dates, intended timezone, and acceptable sample size for each query. State whether you need examples, a bounded comparison sample, or every matching post. Do this before you see the results. Define what makes a row acceptable, including any required author, media, or other filter.
2. Choose the controls and set a small cap. Select the Actor whose documented filters meet the requirement. Choose native date inputs or advanced query operators. For a Chronometrica check, the input above provides a small starting point. Check the generated query before accepting any combination of date controls.
3. Inspect the actual query and post dates. Read `executedQuery` and compare it with `inputQuery`. Confirm that the generated query expresses the intended keyword and date scope. Inspect `createdAt`, the post creation timestamp, for every accepted row. Compare it with your checked timestamp window, including both calendar boundaries. [Chronometrica documentation](https://apify.com/chronometrica/x-search-scraper)
4. Read each query outcome. Compare the saved-row count with the requested cap and reported outcome. Mark a query as capped when it reaches the cap. Mark a partial result when the evidence supports that status. Keep unexplained shortfalls visible. Preserve unknown values as unknown. Do not replace missing data with zero.
5. Accept and export separate query samples. Keep `resultPosition` and record the observation time: when you collected the sample. This differs from the post’s creation time. Retain the original date request and notes about capped or partial queries. Begin analysis only when you can explain what you requested, what you observed, and which limits apply.

A query with fewer saved rows did not necessarily have fewer matching posts across X. Treat its outcome as evidence about that collection. If a required filter cannot be expressed, resolve the product choice before you collect a larger sample.

The acceptance check also gives you a clear stopping rule. You can proceed when the required controls work and the saved records support your planned use. If either check fails, a larger collection alone will not resolve the problem.

## A fictional two-keyword decision

This example is fictional. It is not an Actor test, a live dataset, a buyer quotation, or a measured cost result.

A researcher wants January posts for two keywords: “artificial intelligence” and “machine learning.” The purpose is to collect examples for manual review. The researcher accepts a cap of 10 saved rows for each query and records the intended timezone before collection.

The maximum requested sample, before other limits, is:

`2 queries × 10 rows per query = at most 20 saved rows`

In this fictional result, the first query returns 10 accepted dated rows. The second returns 6 accepted dated rows before its public source ends. The researcher keeps:

`10 + 6 = 16 observed rows`

The researcher also keeps two query outcomes. The first query reached its cap. The second stopped below its cap. Combining the rows must not erase that difference.

For this need, Chronometrica fits the decision. The researcher accepts bounded samples and needs the original query, generated query, row positions, and separate outcomes. Those records let the researcher review the collection against the stated request. [Chronometrica documentation](https://apify.com/chronometrica/x-search-scraper)

The researcher can describe the content of the 16 observed rows. The researcher cannot conclude that the first topic appeared more often across all X. The caps and unequal outcomes do not establish population frequency: how often each topic appeared across the full set of posts.

If the requirement changes to every January match, the researcher must assess that new requirement separately. A successful small sample does not prove a complete collection. If that all-results requirement exceeds Chronometrica’s per-query cap, this Actor does not meet it.

## Keep query records separate from post observations

Use one query-control table to record the request and its outcome. This is your research record, not a claim about an Actor’s export format. For each query, retain the original keyword text, inclusive date request, intended timezone, chosen mode, requested cap, saved-row count, and reported outcome.

Keep post observations separately, keyed by `postId` and `executedQuery`. A key is the set of values used to identify a record. Preserve the link between each post and the generated query that produced it.

Retain the documented search-context fields `inputQuery`, `executedQuery`, `searchMode`, and `resultPosition`. Keep `createdAt` for the date check. Add the observation time to your research records. [Chronometrica documentation](https://apify.com/chronometrica/x-search-scraper)

A post can appear in more than one query sample. Preserve those query links when that happens. They show why the post entered each sample. If you later count unique posts, explain that calculation separately from the number of saved query observations.

This structure helps prevent a common mistake: presenting all exported rows as one unqualified total. A combined file can contain capped samples, partial samples, and repeated posts. The query records let you explain those differences before you draw a conclusion.

For a later analysis of terms that appear together, see [X post keyword cooccurrence](/en/articles/x-post-keyword-cooccurrence/). First establish which observations you can use. Then apply the analysis method to that stated sample.

## Choose Chronometrica for a sample you can review

Choose Chronometrica when its bounded per-query sample and explicit query records meet your study. This is a clear fit for the checked need: a limited keyword sample from a set date range, with enough saved context to inspect each query’s result.

Start with [Chronometrica X Search Scraper](https://apify.com/chronometrica/x-search-scraper). Apply the inputs and acceptance checks above before you expand collection. Keep the required-filter switch condition and saved-row cap in the decision. Make your final research claim only as broad as the observations support.

## Sources

- [Chronometrica X Search Scraper — public documentation and input schema; evidence checked October 20, 2026, cached build 0.1.30; supports the stated input limits, inclusive date controls, search-context fields, and per-query OUTPUT accounting; the example passed an input-shape check, and no collection run was made for this article](https://apify.com/chronometrica/x-search-scraper)
- [Apidojo Tweet Scraper V2 — public documentation and input schema; evidence checked October 20, 2026, cached build 0.0.1557; supports the stated search controls and single-tweet policy; documentation evidence, not a matched performance test](https://apify.com/apidojo/tweet-scraper)
- [Chronometrica X Twitter Search API Dataset Task — public preset page checked October 20, 2026; returned HTTP 200; page availability does not confirm the current saved input or prove collection success; inspect and apply the intended settings before a run](https://apify.com/chronometrica/x-search-scraper/examples/x-twitter-search-api-dataset)
- [Public request for keyword and time-period collection — included in the evidence checked October 20, 2026; supports the buyer need for date-scoped collection; the named comparison is editorial, and the request is not evidence of complete historical coverage, product performance, cost, or collection success](https://www.reddit.com/r/webscraping/comments/19bekjv/is_there_a_current_solution_to_scrap_tweets)