Apify Compatibility

Overview

Fetchin exposes an Apify-compatible endpoint. If you already run B2B data actors through Apify, you can keep your existing code and the official Apify client libraries — you only change the base URL to Fetchin and use your Fetchin API key as the token. Everything runs asynchronously, exactly like Apify: you start an actor run, we queue it, and you poll for the result and read the dataset. Batches are buffered and drained at your plan’s RPS.

Base URL

https://api.fetchin.io/v1/apify

Point any Apify client at that base URL and pass your Fetchin API key as the token. That’s the whole change.

The token here is the same key you send as X-API-Key elsewhere, so rotating it covers this integration too. Create the new key, update the token in your Apify clients, and revoke the old key once it stops being used — both work at once, so nothing breaks in between. Run history and datasets belong to your account, not to a key.

Supported actors

The following Apify actors are supported today. Reference an actor by its raw actor ID or by the username/actor-name form your existing integration already uses — both resolve.

Apify actor	Actor ID	What it returns
`supreme_coder/linkedin-profile-scraper`	`yZnhB5JewWf9xSmoM`	A full professional profile (one item per profile). Input `scrapeCompany: true` adds the current-company block.
`supreme_coder/linkedin-post`	`Wpp1BZ6yGWjySadk3`	A profile’s posts. Input `deepScrape: true` adds reactions + comments per post; `numComments` / `numLikes` set how many of each (`0` skips one). See Input (posts).
`apimaestro/linkedin-profile-comments`	`7TNcROe1C2CQDO3wl`	Comments made by a profile (paginated).
`apimaestro/linkedin-profile-reactions`	`FNhKFjeL8hWQtMeZI`	Reactions made by a profile (paginated).
`harvestapi/linkedin-company-posts`	`WI0tj4Ieb5Kq458gB`	A page’s or profile’s posts. Inputs `scrapeReactions` / `scrapeComments` add each post’s reactions and comments as separate dataset items. See Input (company posts).

We map the output fields to match each actor as closely as possible, so your downstream code keeps working unchanged.

Need another actor? If you rely on an actor that isn’t in this list, reach out via the chat on fetchin.io or email us — we add actors on request.

Usage

JavaScript / Node (`apify-client`)

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({
  token: process.env.FETCHIN_API_KEY,
  baseUrl: 'https://api.fetchin.io/v1/apify', // the only change
});

// Start a run and wait for it to finish
const run = await client
  .actor('yZnhB5JewWf9xSmoM')
  .call({ urls: [{ url: 'https://www.linkedin.com/in/williamhgates/' }], scrapeCompany: true });

// Read the dataset
const { items } = await client.dataset(run.defaultDatasetId).listItems();
console.log(items);

Python (`apify-client`)

from apify_client import ApifyClient
import os

client = ApifyClient(
    token=os.environ["FETCHIN_API_KEY"],
    api_url="https://api.fetchin.io/v1/apify",  # the only change
)

run = client.actor("yZnhB5JewWf9xSmoM").call(
    run_input={"urls": [{"url": "https://www.linkedin.com/in/williamhgates/"}], "scrapeCompany": True}
)

items = client.dataset(run["defaultDatasetId"]).list_items().items
print(items)

HTTP (any language)

# 1. Start a run
curl -s -X POST \
  'https://api.fetchin.io/v1/apify/v2/acts/yZnhB5JewWf9xSmoM/runs' \
  -H 'Authorization: Bearer '"$FETCHIN_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"urls":[{"url":"https://www.linkedin.com/in/williamhgates/"}],"scrapeCompany":true}'
# -> { "data": { "id": "<runId>", "defaultDatasetId": "<datasetId>", "status": "READY", ... } }

# 2. Poll the run until status is SUCCEEDED (waitForFinish long-polls up to 60s)
curl -s \
  'https://api.fetchin.io/v1/apify/v2/actor-runs/<runId>?waitForFinish=60' \
  -H 'Authorization: Bearer '"$FETCHIN_API_KEY"

# 3. Read the dataset (a JSON array of items)
curl -s \
  'https://api.fetchin.io/v1/apify/v2/datasets/<datasetId>/items' \
  -H 'Authorization: Bearer '"$FETCHIN_API_KEY"

Input (posts)

Input	Type	Notes
`urls`	array of strings or `{ "url": … }` objects	One or more professional profile URLs.
`limitPerSource`	integer, 1–100	Posts returned per profile. Default 10. `limit` is accepted as an alias.
`deepScrape`	boolean	`true` adds each post’s `comments` and `reactions`. Default `false`: the Apify actor defaults it to `true`, so pass it explicitly.
`numComments`	integer, 0–100	With `deepScrape`, the maximum number of comments returned per post. `0` skips comments: they are not fetched and not billed. Default 100.
`numLikes`	integer, 0–100	With `deepScrape`, the maximum number of reactions returned per post. `0` skips reactions: they are not fetched and not billed. Default 100.

// Comments only: reactions are skipped, so each post costs 2 credits, not 3.
await client.actor('Wpp1BZ6yGWjySadk3').call({
  urls: ['https://www.linkedin.com/in/williamhgates/'],
  deepScrape: true,
  numLikes: 0,
});

A skipped list is still on every item, as an empty reactions: [] (or comments: []), exactly like the Apify actor. One default differs: when you omit numComments / numLikes, the Apify actor returns 10 of each and we return up to 100. The actor’s other inputs (scrapeUntil, fetchDocumentDetails, rawData) are not supported yet and are ignored.

Input (company posts)

harvestapi/linkedin-company-posts takes a list of page or profile URLs and returns their posts.

Input	Default	What it does
`targetUrls`	—	Page or profile URLs. A numeric page id (`/company/1441/`) and a scheme-less URL both resolve; a bare slug (`google`) does not. `maxPosts` applies per URL.
`maxPosts`	`10`	Posts per URL. `0` means every post the feed will serve.
`postedLimit`	—	`any`, `1h`, `24h`, `week`, `month`, `3months`, `6months`, `year`.
`postedLimitDate`	—	Return posts no older than this date (date string or millisecond timestamp). Combined with `postedLimit`, the tighter bound wins.
`includeReposts`	`true`	Keep posts the page reshared with no commentary of its own.
`includeQuotePosts`	`true`	Keep posts the page reshared with its own commentary.
`scrapeReactions`	`false`	Also return each post’s reactions.
`maxReactions`	`5`	Reactions per post; `0` means all.
`scrapeComments`	`false`	Also return each post’s comments.
`maxComments`	`5`	Comments per post; `0` means all.
`commentsPostedLimit`	—	`any`, `1h`, `24h`, `week`, `month` — bounds comments by age.
`postNestedReactions`	`false`	Also nest the reactions inside each post item.
`postNestedComments`	`false`	Also nest the comments inside each post item.
`contextCountry`	—	Accepted but not applied — this API does not route by viewer region. A run that sets it to anything but `any` says so in its `statusMessage`.

One dataset, three kinds of item

This is the part most worth knowing before you switch. With scrapeReactions or scrapeComments on, the dataset is mixed: reactions and comments are their own items, each with a type field, emitted before the post they belong to.

reaction, reaction, reaction, comment, comment, comment, post,
reaction, reaction, reaction, comment, comment, comment, post, …

Each post then references them by id:

{
  "type": "post",
  "id": "7511096948829966336",
  "reactionIds": ["urn:li:fsd_reaction:(urn:li:fsd_profile:ACoAA…,urn:li:ugcPost:…,0)"],
  "commentIds": ["7511400393126338560"]
}

So filter by type rather than assuming every item is a post:

const items = await client.dataset(run.defaultDatasetId).listItems();
const posts = items.items.filter((i) => i.type === 'post');
const comments = items.items.filter((i) => i.type === 'comment');

postNestedReactions / postNestedComments add reactions[] and comments[] arrays on the post item; they do not remove the separate items. Billing: one credit per dataset item, reactions and comments included — which is how the actor itself charges them.

Reshared posts

Two different things, controlled by two different inputs:

a post reshared with no commentary (includeReposts) comes back as the original post — author is the original author — with repostedBy and repostedAt saying who put it on the requested feed, and a header.text ending in reposted this.
a post reshared with commentary (includeQuotePosts) comes back as the resharer’s own post, with the quoted original nested under repost and its id echoed as repostId.

A page can also reshare someone else’s quote post, in which case the item carries both repostedBy and repost. A collaborated on this header is neither a repost nor a quote post and is never dropped by either input.

Input (comments & reactions)

Both actors accept the published input shape — usernames plus a per-profile limit — and the singular username form:

Input	Type	Notes
`usernames`	array of strings, or a comma-separated string	One or more handles or professional profile URLs. `limit` applies per profile.
`username`	string	Singular alias. Accepted indefinitely; use either.
`limit`	integer, 1–3000	Items returned per profile. We page the source automatically to fill it. Default 20.
`page_number`	integer, ≥ 1	Which page of `limit` items to return. Default 1.
`pagination_token`	string	Reactions only — see below.

// Both of these are valid, and equivalent for a single profile.
await client.actor('7TNcROe1C2CQDO3wl').call({ usernames: ['williamhgates'], limit: 100 });
await client.actor('7TNcROe1C2CQDO3wl').call({ username: 'williamhgates', limit: 100 });

limit is a ceiling, not a target: a run returns min(limit, available) items per profile. Asking for more than a profile has is safe and returns everything it has — the run’s statusMessage then says Confirmed end of feed. You never need to know a profile’s true count in advance.

Pagination (comments & reactions)

Each run returns one page per profile. Increment page_number to walk the feed:

let pageNumber = 1;
for (;;) {
  const run = await client
    .actor('7TNcROe1C2CQDO3wl')
    .call({ username: 'williamhgates', limit: 100, page_number: pageNumber });
  const { items } = await client.dataset(run.defaultDatasetId).listItems();
  if (items.length === 0 || items[0].message) break; // end of feed
  // ... process items ...
  pageNumber += 1;
}

Reaction items additionally carry a pagination_token. Passing it back with the next page_number jumps straight to that position instead of walking there, so it is the cheaper and faster way to page that actor:

const run = await client.actor('FNhKFjeL8hWQtMeZI').call({
  username: 'williamhgates',
  limit: 100,
  page_number: pageNumber,
  pagination_token: token, // from items[0].pagination_token of the previous page
});

Comment items carry no pagination_token (matching the actor we emulate), so comments page by page_number alone.

Telling “no data” apart from “it didn’t work”

A run that could not collect its data in full ends FAILED, never SUCCEEDED with a short or empty dataset. That covers both shapes: a collection that produced nothing, and one that produced some genuine items but was truncated before the feed was exhausted — the harder case, because the payload looks perfectly valid. A truncated run keeps its items in the dataset (they are real, and yours to use), but its status tells you they are not the whole answer. So run.status is a sufficient check:

const run = await client.actor('7TNcROe1C2CQDO3wl').call({ username: 'williamhgates' });
if (run.status !== 'SUCCEEDED') {
  // Transient — re-run it. An identical re-run after a finished run always
  // starts a fresh attempt.
}

When a profile genuinely has no activity of that kind, the run ends SUCCEEDED with a single non-billed sentinel item — { "message": "No comment found for this profile" } / { "message": "No reaction found for this profile" }, matching Apify — and these signals confirm it:

run.statusMessage explains the result ("Confirmed empty: …", "Confirmed end of feed: 12 item(s) available, 100 requested.").
run.stats.creditsCharged is 0 — nothing billable was produced.
Reading the dataset directly, the response carries x-fetchin-run-status and x-fetchin-run-status-message headers, so a consumer that only fetches items still sees the outcome without a second request.

In a multi-profile run, one profile failing does not sink the others: it yields a non-billed { "profile_input": "…", "message": "API request failed", "errorDetails": "…" } item, the rest of the batch completes, and the run only ends FAILED if every profile failed.

Billing, timeouts & retention

Billing: 1 dataset item = 1 Fetchin credit (the same per-result accounting as Apify). A batch of 25 profiles = 25 credits. Exception: a post fetched with deepScrape: true costs up to 3 credits per post: 1 for the post plus 1 for each engagement list (its comments, its reactions). A list you turn off with numComments: 0 or numLikes: 0 is not fetched and not billed, so a comments-only post costs 2. A list we could not collect (the fetch failed, or it came back empty although the post shows comments or reactions) is not billed either. A list that is empty because the post genuinely has no comments or reactions is a delivered answer and is billed. A shallow post (deepScrape: false / omitted) always costs 1 credit.
Timeout: the timeout input (seconds) bounds a run. If it elapses, the run ends TIMED-OUT and the items already produced remain in the dataset.
Retention: run records and datasets are retained for 24 hours. Fetch your results within that window.
Rate: your account RPS controls how fast we drain your queued items (not how many runs you can create). Creating runs far faster than your RPS returns 429 with Retry-After; the Apify client backs off automatically.

Differences vs Apify

We validate every actor against real Apify output field-by-field. The reactions, comments and post actors reach zero field errors on matched items; the differences below are values that either cannot be reproduced byte-for-byte (live counts, signed URLs, per-request tokens) or that we approximate where the source data isn’t exposed. Everything here is stable and documented so you can decide whether it affects your integration. If a specific field blocks you, contact us and we’ll prioritise it.

Applies to all actors

Live engagement counts (reactions/comments/reposts totals) drift second to second — they reflect the source at fetch time, so two fetches rarely match to the digit. This is identical to Apify.
Relative timestamps ("15h", "2w") are wall-clock-relative to the moment of the request. Absolute timestamps (timestamp, postedAtISO, formatted) are exact.
Signed media URLs carry an expiring signature (?e=…&v=…&t=…). The host + path are stable; the signature differs every request.
Pagination tokens are opaque and positional — use them, don’t compare them.

Batch error handling (profile & post)

The batch actors (profile, post) accept many URLs per run. If one URL can’t be fetched (profile not found, a transient upstream error), the run does not fail: the rest of the batch still completes, the run ends SUCCEEDED, and the failed URL yields a single non-billed item:

{ "error": "profile not found", "inputUrl": "https://www.linkedin.com/in/…/" }

You are not charged for a failed URL. Filter results with items.filter((i) => !i.error). A profile that does not exist is final, so don’t retry it; any other error is usually transient and succeeds on a re-run.

`supreme_coder/linkedin-profile-scraper` (profile)

Field	Difference
`currentCompany`	With `scrapeCompany: true` we return a compact block (`name`, `universalName`, `url`). Apify’s full company sub-tree (employee counts, industries, HQ, affiliated pages…) is not fully reproduced yet.
`pictureUrl`, `coverImageUrl`, logos	Dimension-keyed objects (`{"800x800": "…"}`). We currently populate the largest rendition keyed by its real size; other size keys may be absent.
`certifications`, `languages`, `testScores`	Populated from the profile, in a compact shape (`certifications` → `{name, authority}`, `languages` → `{name, proficiency?}`, `testScores` → `{name, score?}`) rather than Apify’s full structured objects (timePeriod, etc.).
`courses`, `honors`, `volunteerExperiences`, `projects`, `publications`, `patents`, `organizations`, `volunteerCauses`	Returned as `[]` (extraction of these sections is in progress).
`mutualConnections`	Always `[]` — depends on the viewer’s network and isn’t available to a service account.
`fullName`	Derived as `firstName + " " + lastName`.
`created`, `trackingId`, `versionTag`, `birthDate`	Not returned. The first three are per-capture tokens. For `birthDate`, the actor’s format when a birthday is present is unknown to us, so we don’t guess it; `GET /api/v1/profile` returns it as `birthDate` (`{ month, day, year? }`) when the member makes it visible. Identity and location fields (`id`, `profileId`, `countryCode`, `geoUrn`, `geoLocationName`, `geoCountryName`, `creator`, `influencer`, `premium`, `pronoun`, `creatorInfo`) are returned and match the actor’s naming.

`supreme_coder/linkedin-post` (post)

Field	Difference
`author.id`, `authorUrn`	The numeric member id / member-scheme urn isn’t present in the source feed. We return the public handle (`author.publicId`, `authorProfileId`) and the profile id (`author.profileId`).
`author.trackingId`, `author.backgroundImage`	Not reproduced (per-request token / not in the feed).
`resharedPost`	Reshared posts are not nested. The underlying feed returns a profile’s own posts; pure reshares are filtered.
`url`	Canonical post permalink. The trailing `?rcm=…` token is per-viewer and will differ.
`linkedinVideo.videoPlayMetadata`	Core fields (streams, duration, thumbnail, aspect ratio) are reproduced; `transcripts`, `adaptiveStreams` and `trackingId` are omitted.
`attributes`, comment `entities`	Inline @mention / hashtag annotation ranges are returned as `[]`.
Deep `comments[]` / `reactions[]`	These are relevance-ranked live lists — the exact top-N set differs between any two fetches (true on Apify too). Per engager: `firstName`/`lastName` are split best-effort from the display name (Apify uses the source’s structured name fields); `publicId` is the profile id (the engager lockup doesn’t expose the handle); `id`, `trackingId`, `backgroundImage`, `distance`, `originalLanguage` are omitted. Names, occupation, picture and `profileId` match.

`harvestapi/linkedin-company-posts` (company posts)

socialContent.hideShareAction / hideSendAction depend on the viewer, not on the post: the same post returns true for one caller and false for another. We return what the source tells us; don’t assert on them.
document.manifest is not returned. The feed carries document.manifestUrl (which we do return) but not the manifest body — fetch that URL directly if you need it.
repost.engagement is omitted, not zeroed, when the quoted post’s own counts aren’t in the feed page. A zero there would read as a fact; fetch the quoted post by its repostId if you need its counts. The run’s statusMessage says when this happened.
author.urn is the numeric id for a page and for a member. On the rare item where the feed doesn’t carry a member’s numeric id, we return their opaque id instead rather than invent a number — profileId is always exact.
A single-post URL (/feed/update/urn:li:activity:…) cannot be served: it names no author, and the only route to a post’s body is its author’s feed. The /posts/<handle>_… form works. An unservable URL is named in the run’s statusMessage rather than silently returning nothing.
contextCountry is accepted and not applied (see the input table).
Post order is the feed’s own order, which is relevance-ranked, not chronological, and shifts between calls — the same as the actor itself. Measured on two separate environments: a 10-post window came back 10-05, 10-04, 10-01, 09-30, 09-29, 10-02, 10-02. Don’t rely on two runs returning the same window.
query.sortBy is an echo of the actor’s own field, not a guarantee. It reads "date" on every item, including ours, because that is what the actor emits — but the order is the one above. So do not paginate “until I reach the date of my last sync”: a post older than your cutoff can be followed by a newer one, and the walk would stop early while believing it had everything. Page on maxPosts (or postedLimit / postedLimitDate, which filter by date server-side) and de-duplicate on id.

`apimaestro/linkedin-profile-comments` (comments)

Full field parity on matched items. Only the volatile values above (live comment/post reaction counts, relative time) differ.
Items do not carry a root pagination_token — this actor pages by page_number (this matches Apify’s actor).
Reaching a deep page_number costs one source request per skipped page, so page sequentially rather than jumping to a high page number.

`apimaestro/linkedin-profile-reactions` (reactions)

Field	Difference
`action`	We return the reaction type enum (`LIKE`, `EMPATHY`, `APPRECIATION`, `INTEREST`, `PRAISE`, `ENTERTAINMENT`). Apify emits a header sentence (e.g. `"Bill Gates likes this"`). Tell us if you need the sentence form.
`post_url`	The canonical post permalink — same post, may be a different valid URL form than Apify’s.
`post_stats` per-type counts	Reproduced (`like`/`appreciation`/`empathy`/`interest`/`praise`), subject to the live-count drift noted above.
`page_number`	Present on every item (the page the item came from). Apify’s reaction items omit it; it is additive, so field-by-field consumers are unaffected.

Getting Started

Core Concepts

Account

Posts

Profile

Company

Apify Compatibility

Overview

Base URL

Supported actors

Usage

JavaScript / Node (`apify-client`)

Python (`apify-client`)

HTTP (any language)

Input (posts)

Input (company posts)

One dataset, three kinds of item

Reshared posts

Input (comments & reactions)

Telling “no data” apart from “it didn’t work”

Billing, timeouts & retention

Differences vs Apify

Applies to all actors

Batch error handling (profile & post)

`supreme_coder/linkedin-profile-scraper` (profile)

`supreme_coder/linkedin-post` (post)

`harvestapi/linkedin-company-posts` (company posts)

`apimaestro/linkedin-profile-comments` (comments)

`apimaestro/linkedin-profile-reactions` (reactions)

​Overview

Base URL

​Supported actors

​Usage

​JavaScript / Node (apify-client)

​Python (apify-client)

​HTTP (any language)

​Input (posts)

​Input (company posts)

​One dataset, three kinds of item

​Reshared posts

​Input (comments & reactions)

​Pagination (comments & reactions)

​Telling “no data” apart from “it didn’t work”

​Billing, timeouts & retention

​Differences vs Apify

​Applies to all actors

​Batch error handling (profile & post)

​supreme_coder/linkedin-profile-scraper (profile)

​supreme_coder/linkedin-post (post)

​harvestapi/linkedin-company-posts (company posts)

​apimaestro/linkedin-profile-comments (comments)

​apimaestro/linkedin-profile-reactions (reactions)

Overview

Supported actors

Usage

JavaScript / Node (`apify-client`)

Python (`apify-client`)

HTTP (any language)

Input (posts)

Input (company posts)

One dataset, three kinds of item

Reshared posts

Input (comments & reactions)

Pagination (comments & reactions)

Telling “no data” apart from “it didn’t work”

Billing, timeouts & retention

Differences vs Apify

Applies to all actors

Batch error handling (profile & post)

`supreme_coder/linkedin-profile-scraper` (profile)

`supreme_coder/linkedin-post` (post)

`harvestapi/linkedin-company-posts` (company posts)

`apimaestro/linkedin-profile-comments` (comments)

`apimaestro/linkedin-profile-reactions` (reactions)