Chronometrica vs API Maestro for Known LinkedIn Post URLs

Which Actor fits your requirement?

Chronometrica fits when your first question is: what happened to each post URL we supplied? Its documented attempted-input rows let you review usable records and unresolved outcomes together. Its separate `activityId`, `ugcPostId`, and `postUrn` fields retain the type of each post identifier. An identifier is a value used to refer to a post. Chronometrica documentation

Use this table for the first choice. It describes checked documentation, not measured performance.

The product facts come from the checked Chronometrica documentation and API Maestro documentation.

If your requirement is more than 1,000 entries in one run, API Maestro does not meet that requirement. API Maestro input documentation

An unknown cap does not mean unlimited capacity. This evidence does not establish a maximum for Chronometrica. Check the actual settings against your planned job before you run it.

Also define what you mean by a complete result. Accounting for each attempted input differs from obtaining usable text from every post. Neither product’s checked public documentation proves complete access to all public posts. If usable text from every supplied URL is mandatory, this evidence does not establish that either tool meets that requirement.

Why attempted-input rows matter

A content review needs usable post text. It also needs an explanation for inputs that did not supply usable text. A table containing only accepted content cannot answer both needs.

Chronometrica’s documented output supports this review. Use `inputUrl` to connect a row to the supplied URL. Read `status` and `statusReason` to understand the reported outcome. Keep `observedAt` so a later reviewer knows when the observation was made. Chronometrica output documentation

Observation time and publication time have different meanings. Publication time tells you when a post was published. Observation time tells you when the collection recorded its state. Keep those meanings separate in your records.

Post identity also needs care. Retain `activityId`, `ugcPostId`, and `postUrn` under their original field names. Do not combine them into one unlabeled value and assume they have the same meaning. The separate fields preserve information that may matter when you connect records later. Chronometrica output documentation

Exact duplicate input strings are checked once. Different URL forms for the same post can produce separate attempts. This is exact-string duplicate handling. It does not promise that all links to the same post will be combined. Chronometrica input documentation

This distinction affects your expected row count. Count the distinct exact strings in the working input list. Do not use an assumed count of unique posts unless you have checked post identity separately. Keep the original list so you can explain what changed during preparation.

These records help answer a practical question: why does the accepted content table contain fewer rows than the supplied list? Recorded outcomes give you an answer without a later attempt to reconstruct the collection.

Use a five-step acceptance check

An acceptance check decides whether each collected row meets your stated need. Define the rule before the full job. A finished run alone does not prove that its rows are suitable for your work.

1. Prepare the exact input list.

Keep a copy of the original URLs. Create a working list that removes exact duplicate strings. Record the number of entries before and after that step. Use the working list to set your expected attempt count.

For Chronometrica, use public `/posts/` URLs. Only that URL pattern fits the checked input evidence. Do not substitute a `/feed/update/` URL in this method. If several links appear to refer to one post, keep that question for review. Do not assume the Actor will combine them. Chronometrica input documentation

1. Define what an accepted row must contain.

Write down the fields your next task requires. Content coding means assigning labels to content for analysis. It needs usable text and a source URL. Input accounting also needs the attempt outcome. Later record matching may need the available typed post identifiers.

Define usable text for your task. A short post may be complete and useful. Empty text needs review before content analysis. Do not use text length alone as the acceptance rule. Decide whether a missing count blocks your work or whether you can use the text without that count.

1. Check a small list against the returned outcomes.

Choose a small number of inputs that you can inspect row by row. Set that limit before the check. Use the chosen Actor’s actual settings. This check asks whether its documented behavior fits your work; it does not establish a general success rate.

For Chronometrica, connect attempts to the working list through `inputUrl`. Read `status` and `statusReason`. Compare the returned text with your acceptance rule. These documented fields support the input-to-result check. Chronometrica output documentation

If input and output totals differ, investigate the difference. Check exact duplicate strings, URL forms, and reported outcomes. Do not fill an unexplained gap with an invented success or failure record.

1. Keep unknown counts separate from zero.

Zero is a known numerical value. A `null` count means the value is missing. Chronometrica documents that missing public counts remain `null`. Preserve this distinction when you export or calculate results. Chronometrica count handling

Do not describe a missing count as no activity. If you calculate an average, state how many records had known values. Do not replace missing counts with zero. Review empty text separately: a known count does not prove that a row contains the content your analysis needs.

1. Export accepted content and retain excluded outcomes.

Create a content table with rows that pass your rule. Keep source URLs and observation time. Store excluded input outcomes in a separate audit table. An audit table records what you checked and why you accepted or excluded each item.

Use these acceptance columns: `inputUrl`, resolved URL, typed post identity, `status`, text usable yes/no, `observedAt`, and accept/review reason. These are review columns. They do not imply that every label is an Actor output field. Preserve unknown values instead of inventing a resolved URL or identifier.

Check that accepted and excluded outcomes together account for the working input list. Keep the reason for each exclusion. A later reviewer should be able to distinguish missing text, an unavailable input, and a failed attempt without guessing.

Prepare the input before your check

The LinkedIn Post Text & Engagement Data Task offers a starting preset. A Task is a saved input preset. Its public page returned HTTP 200 when checked for this brief. That confirms the page was available; it does not verify the Task’s current saved input. Inspect the input and apply the current schema settings before a run.

A schema defines allowed input fields and values. The following input passed a local format check against the saved public schema. Its field name exists in that schema. The check did not prove that the source post was available. No collection run was made for this brief. Chronometrica input documentation

{
  "startUrls": [
    "https://www.linkedin.com/posts/timferriss_i-took-my-whole-genome-dumped-it-into-ai-activity-7333162625675038720-TJPX"
  ]
}

The example URL comes from the saved public schema or example. Replace it with your intended public source. Do not treat it as a newly collected result.

The checked schema requires `startUrls` to be an array with at least one item. An array is a list of values. This minimum does not establish a maximum input size. Use your small working list for the first check, then compare the returned rows with that retained list. Chronometrica input schema

Inspect the preset even if its name matches your task. The page check and the input-format check answer different questions. One concerns the public page. The other concerns the allowed input structure. Neither replaces the row acceptance check after collection.

A fictional 12-URL decision

The following example is fictional. It is not an Actor test, a customer result, a buyer quote, or a measured cost comparison.

A researcher has 12 distinct exact URL strings. The job requires post text for content coding and a record of each attempted input. This requirement fits Chronometrica’s documented input-accounting strengths.

In the fictional check, nine rows contain usable text. Two rows explain unavailable inputs. One row explains a failed attempt. The researcher keeps all 12 attempted-input rows but accepts only the nine usable rows for content coding.

The arithmetic is:

• 9 usable rows + 2 unavailable-input rows + 1 failed-attempt row = 12 attempted inputs.
• 9 ÷ 12 = 75% usable rows in this fictional check.

The 75% figure describes only these invented outcomes. It is not a product success rate. The 12 attempts also do not represent 12 successful paid results. Failed attempts are not successful paid results under Chronometrica’s documented contract. Chronometrica documentation

The researcher now has two useful records. The content table supports analysis of nine posts. The audit table explains why three inputs did not enter that analysis. Keeping both prevents someone from assuming that the original list contained only nine posts.

The nine accepted rows can be suitable for content coding while the original requirement for usable text from all 12 remains unmet. Acceptance for one purpose does not erase that gap. The researcher must keep the distinction clear when sharing the result.

If the job instead starts from bare IDs and needs only resolved detail records, API Maestro may fit better. API Maestro documentation

What the evidence establishes

The product evidence was collected on 20 October 2026. The checked builds were Chronometrica 1.0.60 and API Maestro 0.1.18. These are dated documentation findings. No new matched test was made for this article. Chronometrica public contract, API Maestro public contract

The evidence supports a choice based on documented input and output behavior. It does not support claims of lower cost, faster collection, better accuracy, or better reliability. No failure-row or data-loss defect was tested for the alternative. Undocumented behavior remains unknown.

The buyer need has a clear boundary too. A public discussion asked about collecting LinkedIn posts for a lead bot. It did not request this vendor comparison or an input-to-result check. This article adapts that collection need to the stage where the reader already has public post links. The named comparison is our editorial choice. It does not promise qualified leads, profile discovery, or outreach. Public discussion of LinkedIn post collection

After collection, assessing claims inside the posts is a separate task. Use accepted text and source URLs with How to Compare Claims and Supporting Evidence in LinkedIn Posts. That guide examines evidence within content. This comparison selects the collector and defines the checks needed before that analysis begins.