# Changelog of Facebook Page Reels Scraper — Facebook Reels API, Views, MP4 (`steadyfetch/facebook-reels-scraper`) Actor - **URL**: https://apify.com/steadyfetch/facebook-reels-scraper/changelog.md - **Full Actor documentation**: https://apify.com/steadyfetch/facebook-reels-scraper.md ## Changelog ### 1.0.43 — 2026-10-12 - **A repeat run no longer reads again the reels your account already has.** A run on a page started at the top of its reels and read every listing page down to where your last run stopped — page after page of reels you already had, none of them charged, before it reached anything new. It now keeps where your last run stopped on each page, and once it meets a listing page of reels you already have it goes straight on from there. A scheduled run now reads a few pages instead of all of them, so on the Apify free plan one run no longer uses up the reads a later run that day needs. If that point no longer works, the run reads on from where it was, exactly as before. With "Include reels you already have" on, every reel is read again, as before. - **Reels you already have no longer count against how deep one run reads.** On a paid Apify plan, a run asking for more reels behind ones you already have — for example 700 more after a first run of 600 — now reads as many new listing pages as the new ask needs, so it is no longer cut short by the pages of reels you already had. - **On the Apify free plan, a daily schedule that starts a few minutes early is no longer held for a day.** The free plan allows 30 reads from Facebook per account in any 24 hours. A run that arrives up to 30 minutes before those 24 hours are up is now let through, and the next 24 hours count from it. The row of a held run still names the full 24 hours. - **A run that reaches its own limit now says so plainly.** Its rows read "This run reached its limit: N of M delivered." followed by when a new run can fetch the rest, and their status value is now `limit_reached`. The run page names that count in words instead of an internal code. - Nothing changes about the price, which rows are charged, the input fields or the output columns. ### 1.0.42 — 2026-10-11 - **A "page not found" row now says when the link is probably a personal profile.** This actor reads public Facebook Pages, and most personal profiles cannot be read: such a link opens fine in your own browser, yet came back as "Facebook has no page" with nothing else to go on. The row, and the run page of a run that delivered nothing, now say that this actor reads public Facebook Pages and cannot read most personal profiles, so a link that opens for you may be a personal profile rather than a Page. The row is still uncharged, and the input field's description says the same. - **On the Apify free plan, a link that comes back as not found no longer uses up your daily allowance.** A page or reel link that is not found used to count as one of the 30 reads a free plan account gets in any 24 hours, so a few runs of wrong links could hold every run after them until the next day. Such a read is now given back as soon as the answer arrives, both to your account's allowance and to the shared daily allowance on this actor. A read that lists reels still counts exactly as before, and paid plans are untouched. - Nothing changes about the price, which rows are charged, the input fields or the output columns. ### 1.0.41 — 2026-10-10 - **A page link that carries the page's number now reads that page.** Facebook shows a page with no username as a link like `facebook.com/people//` or `facebook.com/p/-`, and older links look like `facebook.com/pages//` or `facebook.com/pg/`. These were read as a page called "people", "p", "pages" or "pg", so the run found no page and returned none of its reels. They now list the page itself, exactly as `facebook.com/profile.php?id=` does. - **A Facebook link that is not a page is now refused by name, and nothing is charged for it.** Links to a photo, an album, notes, friends, messages, a share or plugin link, a fundraiser, live, saved items, notifications, privacy or policy pages, places or a watch party were read as a page with that name, and could come back as "page not found", as an error asking you to re-run, or even with a reel that had nothing to do with your link. Each now gets one uncharged row saying it is a Facebook link but not to a page or a reel, and what to paste instead. - Nothing changes about the price, which rows are charged, the input fields or the output columns. ### 1.0.40 — 2026-10-09 - **A busy speech service no longer costs you transcripts.** When the speech service behind this actor asked a run to slow down, the reel was given up after two short retries and shipped without its transcript, even with plenty of run time left. The run now waits as long as the service asks, pauses its next transcript until then, and asks again; while it waits, the run log says so. Only when the wait cannot fit in the time the run has left does a reel ship without its transcript, uncharged for the words, on a row that says the speech service was at capacity for this run and to re-run it in a few minutes to get the transcript, and the status line says the same. The reels themselves, and every transcript delivered, are charged exactly as before. ### 1.0.39 — 2026-10-05 - **A date this actor cannot read now stops the run before anything is read, and nothing is charged.** Until now an unreadable "Only reels posted after" or "Only reels posted before" got one uncharged row, and the run went on without that date, so it delivered and charged reels your date was meant to leave out. The same was true of a window that cannot match any reel: a "posted after" date that falls after your "posted before" date, or one more than a day in the future. Each of these now ends the run at once. One uncharged row names the field and says what to type, every page and reel link you named gets an uncharged row saying it was not read, and the run page says nothing was charged. - **A date with no year is no longer guessed.** A value like `Oct 1`, `1 September` or `1` was read as that day in 2001, and a run with it filtered on a window you never set. Such a value now stops the run for $0 with a row saying what to type. So does a day that does not exist, like `Feb 30, 2026` or `2026-02-31`, which used to roll over into March, and a date after 2099 or a written-out one before 2010, like `1/1/2005`. - **Every date with a full year from 2010 to 2099 that worked before still works, and means the same day.** `10/05/2026` is still read month first, as 5 October, and so are dates written with dashes or dots the same way; dates copied from a program, like `Mon Oct 05 2026 00:00:00 GMT+0000` or `Mon, 05 Oct 2026 00:00:00 GMT`, are read exactly as before. When a date like `01/10/2026` could also be read the other way, the run uses the month-first reading as it always did and adds one uncharged note naming both days; writing it year first, like `2026-01-10`, removes the doubt. - **More of the dates people type are now read:** `today` and `yesterday` (from midnight UTC), spans like `last 7 days`, `1 month ago`, `past year`, `2 wks` or `1y` counted back from when the run starts, `25/12/2025` (it reads only one way), `1st October 2026`, and a Unix timestamp in seconds or milliseconds. Quotes around a timestamp no longer matter. - Nothing changes about the price, which rows are charged, the input fields or the output columns. ### 1.0.38 — 2026-10-03 - **A short run timeout no longer skips the one reel when transcripts are on.** With "Include transcript" on, the run held back the same time to finish its report however short the run was, so a run of about a minute (for example a 58-second run timeout through the API, or a run timeout of 50 seconds with "Max run seconds" left at its default) could stop before reading anything and return an uncharged time-limit row. The time held back for the report is now sized to the time the run really has, so one pasted link or one page's reel is read, transcribed and delivered in a run of about a minute. Runs of 80 seconds or more hold back exactly what they did before, and runs without transcripts are unchanged. - **The note about a "Max run seconds" outside 30 to 3,600 names the real limit.** When the run's Timeout setting was shorter than the value this actor used instead, the uncharged note row said the run continued at that value. It now says the run timeout is what limits the run, and what to set it to. - Nothing changes about the price, which rows are charged, the input fields or the output columns. ### 1.0.37 — 2026-10-03 - **A run whose maximum cost per run was too small for even one reel no longer says that maximum was reached.** When your maximum cost per run could not cover a single reel (or a single reel with its transcript, with transcripts on, or a single pasted link), the run stopped before anything was charged, yet the run page, the summary row and the skipped rows all said your maximum had been reached. They now say the run stopped before any charge because the maximum leaves no room for one reel, and to raise it to collect more. A run that charged reels before its maximum ran out reads exactly as before, and nothing changes about the price, which rows are charged, the input fields or the output columns. ### 1.0.36 — 2026-10-03 - **A date window that cannot match any reel is no longer used as written.** A "posted after" date that falls after your "posted before" date, or a "posted after" date more than a day in the future, used to drop every reel, so the run delivered nothing even though the page had reels. Such a window is now set aside exactly like a date this actor cannot read: one uncharged row names the field and says why, and the reels are collected as if that date were not set. When "posted after" falls after "posted before", neither date is used, because nothing says which of the two was mistyped. A "posted before" date in the future is not an error and still works as before. - **A date this actor could not use no longer counts as part of what you asked for.** Its row was counted as one item of your ask beside the reels, so a run that delivered all 10 reels it was asked for read "10 of 11", and the run page suggested adding a page to a run that already had one. The row is still there and still uncharged. It no longer changes the count or the run page's advice. A link this actor cannot read still counts, as before. - **Settings sent inside a `payload`, `data` or `body` object are now read as the run input.** Webhook and automation tools often send a run's settings nested one level down, for example `{"payload": {"pages": ["ladbible"]}}`. Until now only a nested `input` object was read that way. These are now read as if the settings had been sent at the top level, and one uncharged note row says which object they came from. A setting you also put at the top level keeps your top-level value. - **Two runs of one account finishing at the same time no longer erase each other's last memory update,** so a reel one of them delivered stays remembered and a later run hands it back instead of charging it again. - Nothing changes about the price, which rows are charged, the input fields or the output columns. ### 1.0.35 — 2026-09-28 - **On the Apify free plan, this actor now has a daily allowance.** One account on the free plan reads from Facebook at most 30 times in any 24 hours (one listing page of about ten reels, or one pasted reel link, is one read), which covers one full run of the default 30 reels. All free plan accounts together also share a daily allowance on this actor, which resets at midnight UTC. When a run reaches either, it stops cleanly: nothing past that point is read or charged, and every input it did not reach gets an uncharged row that says which allowance it reached, the time it resets in UTC, and that paid Apify plans carry no daily allowance. The run page says the same. Runs on a paid Apify plan are unchanged: no daily allowance, same rows, same charges. - **A pasted reel link to a reel in your "Skip reels in this dataset" dataset is no longer read before it is handed back.** If that dataset holds the reel from a pasted link that was read in full, the reel now comes back as an uncharged repeat without being looked up again, the same as a reel your account's memory already holds. A reel that dataset holds only from a page listing is still read on a paid plan, so its row carries the like, comment and share counts, and on the Apify free plan it comes back without them, with a row that says so. Nothing changes about the price, which rows are charged, the input fields or the output columns. ### 1.0.34 — 2026-09-27 - **A run now says so when some of its updates to your account memory did not save.** The memory is what keeps a reel you already have from being charged again on a later run. If the store behind it does not answer for some of this run's updates, one uncharged row now gives the count and says that a reel delivered here could be charged again if a later run meets it, and the run summary says it too. A run whose memory saved normally reads exactly as before. Our internal run record also now notes why a pasted link to a reel you already have was still looked up, for example because "Include reels you already have" was on or the link was a share link with no reel number. Nothing changes about the price, which rows are charged, the input fields or the output columns. ### 1.0.33 — 2026-09-26 - **A paid run's check no longer holds a run on the Apify free plan in the same hour.** On the Apify free plan a page is read at most once an hour; that hour now starts only from a check made by a run on the Apify free plan, so such a run after a paid one reads the page. A transcript not attempted because this run reached its own budget for this run on reels with nothing chargeable in their audio now says exactly that. The run also now notes its own start in its internal record, so a run cut off before it finishes (a hard abort, a crash or a timeout) is still accounted for on our side. Nothing changes about what is delivered, which rows are charged, the price, the input fields or the output columns. Every entry here is one build on the Builds tab, 1:1, newest first. ### 1.0.32 — 2026-09-26 - **A large run on a paid plan now reads through to the end of its ask, and a run that does stop on this actor's own data limit now says what is true.** A paid-plan run that asked for many reels at once, for example two hundred reel links plus a couple of pages, could stop part-way on a fixed data limit of this actor's own and its rows said the actor had reached a monthly limit that resets at the start of the month. That was wrong: the limit was for that one run, and a re-run collects the rest straight away. That limit now grows with the size of a paid ask, so such a run reads everything it was asked for. When a run does stop on it, its rows and status line now say to start it again for the rest, and that reels you already have are not charged again. Reels that were not delivered are still not charged. No price, charged event, input field or output column changed. ### 1.0.31 — 2026-09-25 - **A `facebook.com/watch/live/?v=` link is now read as that one video** and charged as one reel lookup when its row lands, like a `facebook.com/watch/?v=` link. - **Links this actor cannot read are now refused with a sentence that names what you pasted.** A post share link (`facebook.com/share/p/…`), a `permalink.php` or a `story.php` link is one Facebook post, not a reel, and its row now says so in every box, including "Facebook pages". A `facebook.com/watch//` link and a `facebook.com/share/` link without `/r/` or `/v/` get a row naming that shape and the link to paste instead. As before, nothing is collected or charged for any of them. - **A run that stops because the rest of your ask is too small to pay for reading another listing page now says that this limit is the actor's own.** It used to say "your maximum cost per run was reached", even when your maximum cost per run was nowhere near spent. The row now says it is this actor's own limit and not your maximum cost per run, the run page and the summary row name it as this actor's own limit, and all three say that asking for more reels in one run lets it read further. - **When your maximum cost per run is reached before a page is read at all, that page's row now says the run "stopped before it reached" it,** instead of "stopped part-way through" it. - **The row for a date window this actor did not reach in one run now gives advice that works.** It said "ask for more reels so the run reads deeper", which only helps once a page is asked for more than 150 reels. It now names that number, and when the run already read as deep as one run can, it says a bigger ask would not read deeper and to widen the window instead. - **On the Apify free plan, two runs of one account at the same time no longer erase each other's remembered share links,** so a share link one of them matched is not read again by the next run. No price, charged event, input field or output column changed. ### 1.0.30 — 2026-09-24 - **A short run with "Include transcript" on now uses its whole clock.** Until this build a run with the transcript on stopped taking new reels once 90 seconds were left, however quickly its reels were actually being transcribed — so a run with a 3-minute time limit stopped at about its halfway mark, and a run of 90 seconds or less transcribed nothing. The run now keeps back what its own reels have actually been taking (with a safe minimum, and more for a long reel), so it keeps collecting while another reel and its transcript still fit; a reel longer than the 180-second transcript ceiling, which is never transcribed, no longer counts against the clock. When the time left truly cannot fit another reel, the rows it could not reach and the run's status line now name the run time that would have fit the whole ask, for example "set the run timeout and "Max run seconds" to at least 3 minutes (180 seconds)". Reels that were not reached are still uncharged, and a transcript the clock can no longer finish is not attempted, is not charged and says so on its row. A run with plenty of time behaves exactly as before, and no price, charged event, input field or output column changed. ### 1.0.29 — 2026-09-24 - **Settings sent wrapped in an extra "input" object are now read.** A run whose input arrives as `{"input": {…}}` — for example from `run_input={"input": {...}}` in the Python client — now reads those settings as if they were sent directly and adds one uncharged note row naming them. Before, the run stopped with a guidance row and collected nothing. Nothing changes about the price, the input fields or the output columns. ### 1.0.28 — 2026-09-24 - **On the Apify free plan, a run that was cut short no longer counts as the page's hourly check.** Until this build any run that read a page started that page's hour — even one its time limit, your maximum cost per run or your item limit stopped part-way, or one Facebook stopped answering on. Its row asked you to re-run for the rest, and a re-run inside the hour then read nothing and said the page had been checked with nothing new. Now only a run that read the page to its own end counts as the check — the listing running out, reels your account already has, the edge of your date window, or this actor's own page bound — so the re-run a cut-short row asks for reads on and collects the rest. A run on a paid plan reads the page every time, exactly as before. Nothing changes about which reels are charged, the price, the input fields or the output columns. - **On the Apify free plan, pasting back the reels a page run just delivered no longer reads each one again.** A link to a reel your account already has — including one it got from a page, the link the page row itself gives — now comes back straight from your account's memory, with no result fee, instead of being read again only to fetch its like, comment and share counts. The row says those counts were not read again and how to get them (turn on "Include reels you already have"). A run on a paid plan still reads such a link for its counts, exactly as before. - **On the Apify free plan, a share link is read once and remembered.** A share link carries no reel number, so the run has to read it to learn which reel it is; that answer is now kept for your account, so the same share link pasted again is matched without a read. At most 10 share links an hour that turn out to be reels your account already has are read; past that, the rest wait for the next hour on an uncharged row that says when to re-run, and the reel's own facebook.com/reel/ link is always matched without a read. A share link to a reel you do not have yet is always read and delivered. A run on a paid plan is never held. Nothing changes about which reels are charged, the price, the input fields or the output columns. ### 1.0.27 — 2026-09-24 - **A reel link your account already collected as a link now comes back straight away.** When a pasted link names its reel by number (facebook.com/reel/, facebook.com//videos/ or a watch link) and an earlier run already delivered that reel to your account from a link, the row now returns at once, marked `repeat: true` with no result fee, instead of the reel being read again first. That row carries the reel's id and link; its counts and caption are in the run that first delivered it, and "Include reels you already have" reads them again, still with no result fee. A reel your account only had from a page listing is still read in full when you paste its link, so you still get the like, comment, share and view counts a page listing does not carry. With "Include transcript" on, a reel whose transcript your account never got is read and transcribed exactly as before. - **More Facebook link shapes are read instead of refused.** A link wrapped in Facebook's own redirect (`l.facebook.com/l.php?u=…`), a link pasted inside angle brackets (``), and a link on the short `fb.com` address are now read as the link inside them. A `facebook.com/videos/` link with no page name is now collected as that one video, where it used to be listed as a page called "videos". - **A post link in "Reel links" is now refused instead of listing that page's reels.** A `facebook.com//posts/` link names one post, not a reel, so it now gets one uncharged row naming the reel link shapes to paste instead, rather than listing the whole page's reels and charging them as page reels. In "Facebook pages" it still lists that page's reels, as before. - **The restart handling from 1.0.23 now has a second line of defence.** If the restarted part of a run still ends up reporting nothing delivered, the run's internal record keeps what the first part delivered and charged, with a note of the restart, instead of reading as if nothing had been delivered; one line in the run log says so. Nothing changes about what is delivered, which reels are charged, the price, the input fields or the output columns. ### 1.0.26 — 2026-09-23 - **A link this actor cannot read no longer uses up your result limit.** Each line it could not read took one place of your "Max reels to return" before any readable link, so a run with 30 unreadable lines under the default limit of 30 skipped every good link and delivered nothing. Unreadable lines still get one uncharged row each that says why, but the whole limit now goes to the reel links and pages the run can read. Nothing about prices, charged events, input fields or output columns changed. ### 1.0.25 — 2026-09-23 - **A run billed at the Apify free plan column now reads at most twenty listing pages of reels your account already has, instead of up to one hundred.** Since 1.0.23, pages made up entirely of reels you already have do not count against the page limit your ask sets, and a run walks through them up to a hard limit of one hundred pages to reach the new reels behind them. On the free plan column that hard limit is now the ordinary twenty pages, so a scheduled re-run of a page you have already collected stops sooner when there is nothing new. Runs on any paid plan read exactly as before. No row, charge, price, input field or output column changed: reels you already have are still skipped and never charged, and the run still names the limit it stopped at. - **A re-run of a page that has posted nothing new now stops after the first listing page.** The run now remembers, in your own account's storage beside the reels you already have, what a page's first listing page held and whether an earlier run read that page to the end. If the first page is unchanged and the rest was already read, the run stops there instead of reading through reels your account already has, and the row says so: "checked at 09:05 UTC, nothing new since 08:41 UTC". New reels at the top of the page, "Include reels you already have", a date window, or a run without access to your account's storage all read the page exactly as before. - **On the Apify free plan column, one page is checked at most once an hour.** A re-run of the same page inside that hour reads nothing and charges nothing, and its row says when the page was last checked and when a fresh check is possible. Runs on any paid plan are never held back this way. The store page states the window. No price, input field, output column or charged event changed. ### 1.0.24 — 2026-09-23 - **"Facebook pages" is no longer marked as a required field, and the input now accepts an empty value in any of the three link boxes.** It never had to be filled in — an untouched Start already ran the built-in sample, and reel links alone always worked — but some AI-agent tools read "required" literally, and tools that send an empty value for every box they have nothing for were refused before the run began. Leaving the boxes out, or sending them empty, now runs the sample exactly as before; a run with your pages or links is unchanged. - **The top of this page now says how to come back for fresh reels:** how often pages post, how to put the same input on a schedule, and that reels already delivered to your account are skipped and not charged again. Nothing about what is collected, delivered or charged changed, and no price changed. ### 1.0.23 — 2026-09-23 - **A re-run that asks for a few reels now gets past the reels your account already has, however many that is.** A run reads a number of listing pages sized to what you ask for — twenty pages for a small ask — and every page of reels you already had used up one of them. So if an earlier run had already collected the first two hundred reels of a page, a re-run asking for ten more read those two hundred again, reached its page limit, and stopped with nothing new — and asking for more reels only helped past about one hundred and fifty. Pages made up entirely of reels you already have no longer count against that limit: the run walks through them, still without a row or a charge for any of them, and collects your ten new reels from the pages behind them. The same holds with "Only reels posted before" set, when the reels you already have are also the ones newer than your date. There is still a hard limit on how far one run reads, and the run names it when it gets there. Pages your date window empties of reels you never collected still count against the limit exactly as before. - **A run that Apify moves to another server part-way through now reports the reels the first server delivered as delivered.** The run already picked up where it left off without charging any reel twice, but the new server counted from zero: a run of 20 whose first server had delivered 7 said "Delivered 13 of 20" and wrote a row saying 7 reels had not been delivered — about 7 reels sitting in your dataset. The count, the run page and the rows now all agree with your dataset, and a reel link the first server already answered is not looked up again. - **One stuck transcript request can no longer hold up the whole run for minutes.** Reels are transcribed one at a time, and a speech request that never answered was given three minutes, three times over — up to about nine minutes on one reel before the run moved on. A request now gets a time limit sized to the reel's own length (20 seconds for a 30-second reel, 90 seconds for the longest reel this actor transcribes), is retried once straight away if it runs out, and never runs past your "Max run seconds". A reel whose transcript still does not come back is delivered without it and without a transcript charge, as before. - **The store page now says how to make a run faster.** With transcripts on, a run at the default 1 GB of memory gets through about twice as many reels a minute as at 512 MB, and 2 GB is faster still; the price per reel is the same at any memory. No price, input field, output column or charged event changed in this build. ### 1.0.22 — 2026-09-22 - **The run log no longer prints an internal usage summary at the end of a run, and a failed internal bookkeeping write no longer prints where it was being saved.** Nothing changes about what is delivered, which rows are charged, the price, the input fields or the output columns. ### 1.0.21 — 2026-09-22 - **The run log no longer prints internal cost lines, and the row a run writes when this actor's own monthly collection allowance runs out no longer quotes a dollar figure.** That row still says why the run stopped and that the allowance resets at the start of each month. No price, input field, output column or charged event changed. A transcript that fails no longer passes on the speech service's own error message and links either; the row says so in plain words. ### 1.0.20 — 2026-09-22 - **A run asking for reels posted before a date now walks past the newer ones to reach them, instead of stopping after two pages and saying you already had everything.** Facebook serves a page's reels newest first, so "Only reels posted before" is reached only by reading past everything newer than it — and those pages deliver nothing by construction. The previous build already knew not to stop on pages of reels your account had collected on an earlier run, but it counted a page your own date window emptied as a dead end, which is the same thing for the opposite reason: two of them ended the run and the uncharged row said it had stopped on pages adding nothing new, on reels it had never even checked against your account. Those pages are now walked through, the same way and for the same reason as reels you already have, still without a row or a charge for any of them. A run that reaches the pages this actor reads for one page without meeting your window now says your window starts further down the listing than one run reads and names the two things that fix it — widen the window, or ask for more reels so the run reads deeper — instead of reporting it as the page having nothing. "Only reels posted after" works the other way round: the reels you want are nearer the top and the run has already passed them, so a page it empties is still a dead end and the run still stops there, exactly as fast as before. A feed genuinely repeating itself also stops exactly as fast as before. No price, input field, output column or charged event changed, and reels a date window drops are still never charged. ### 1.0.19 — 2026-09-22 - **A run billed at the Apify free plan column now says so on its own run page, and names what the same run costs on a paid plan.** This actor's prices fall with your Apify plan — a reel from a page listing is $0.003 on the free plan and $0.001 from Gold, a pasted reel link $0.012 and $0.005, a transcript $0.015 and $0.0075 — and the whole table has been on the store page since the first build. The run page, which is the surface you are actually looking at while a run spends your credit, said nothing about it: a free-plan buyer watching $0.012 go on every pasted link had no way to see from that page that the same run is $0.005 a link one plan up. The status line now carries one sentence saying which column billed the run and what each paid rung costs, and it quotes only the doors the run actually used — a run built from page listings is never quoted the pasted-link price, and a run with transcripts off is never quoted the transcript price. Every number in it is read from the same price table the run charges from, so it cannot drift from what you are billed. On a crowded run the sentence is the first thing dropped to make room, because it is a standing price the store page carries in full while everything else on that line is a fact about your run. A run on a paid plan reads exactly as it did before. No price, input field, output column or charged event changed. ### 1.0.18 — 2026-09-21 - **A run that asks for hundreds of reels now reads far enough to find them, and a re-run walks past the reels your account already has instead of stopping at them.** Two separate limits of ours were cutting deep asks short, and neither of them had anything to do with the page running out. The first was a flat ceiling of twenty listing pages per page in a run, written when nobody had asked for more than thirty reels: ask for five hundred and you got two hundred, with an honest row saying the rest was never collected. That ceiling now grows with what you ask for — enough pages to reach your own limit, with a bound so a single page can never run away — so five hundred asked for is five hundred delivered where the page has them. The second was the backstop that stops the run buying listing pages that add nothing: it could not tell a feed repeating itself apart from pages of reels your account simply collected on an earlier run, and treated both as a dead end. A re-run therefore met ten or twenty reels it already had, concluded there was nothing more, and stopped — while the reels you were asking for sat one page further down. Pages of reels you already have are now walked through rather than stopped on, still without a row or a charge for any of them, and the run keeps going until it finds new ones or the listing genuinely ends. A feed that really is repeating itself still stops exactly as fast as before. - **A reel your account already has, whose transcript never came back, is now handed over with the transcript — and the reel itself is still never charged twice.** Until this build the only thing your account remembered about a delivered reel was that it had been delivered. So if a run collected reels with "Include transcript" on and some of those transcripts did not come back — the speech step failed, or an earlier build's own allowance refused them — those words were out of reach for good: every later run saw a reel the account already had and handed it back, or skipped it, without ever asking for the words. Now the memory also remembers whether the transcript itself arrived. Where it did not, the reel comes back marked as a repeat with no result fee for the reel, the transcript is fetched, and that transcript is the only thing charged on the row — which the row says in those words. Nothing is ever bought on a guess: a reel remembered before this build carries no record of its transcript either way, so it is left alone rather than re-charged, and you can reach those older reels' transcripts by putting the earlier run's dataset in "Skip reels in this dataset", which is read per row for what each transcript actually did. A reel already answered as having no speech, no audio track, or being longer than the length ceiling is never asked again — that answer does not change. No price, input field, output column or charged event changed. ### 1.0.17 — 2026-09-21 - **Every reel in a run is now transcribed, however many that is; before this build a run stopped transcribing after about seventy of them.** The transcript leg keeps a small per-run allowance so that a page full of silent or music-only reels cannot buy speech recognition all day for words that are never there. Reels whose transcripts were actually produced and charged were supposed to pay that allowance back as they went, and they were not — so the allowance was a fixed ceiling of roughly seventy transcripts per run no matter how much the run had delivered, and reel seventy-one onward came back with an empty transcript and a note about an allowance the run had in fact more than earned. On a long run that was most of the reels you asked for, handed over without the words. A transcript that is produced and charged now pays its own way and a little more, so a run that keeps delivering keeps transcribing; a run whose audio really does yield nothing chargeable still stops at the same point it always did, and is still charged for none of it. Two row notes are also true now where they were not: a reel we could not transcribe no longer tells you to re-run for it, because your account remembers that reel and a later run hands it back rather than transcribing it again — the note names our Media Transcriber, which takes the reel's link and charges by the minute. No price, input field, output column or charged event changed. ### 1.0.16 — 2026-09-19 - **The whole "Maximum cost per run" you set is now spent on reels; before this build the run held back about a twelfth of it.** Your cap pays for reels and nothing else — the compute, the proxy and the data behind the run are ours, not yours — but the run was still reserving roughly 8% of your cap against those costs before it planned a single reel. So a cap worth ten reels bought nine, and the tenth was money you had authorised and could not spend. That reserve is gone. A run at its cap still ends the same honest way it always did: it stops itself, tells you what it cut and why, and charges you for nothing it did not deliver. No price, input field, output column or charged event changed. ### 1.0.15 — 2026-09-18 - **When the run summary is too long to fit, what gives way is the support ask, never the sentence saying what you were not charged for.** The run page cuts its status line at 500 characters, and on a long run the line used to drop the count of reels your account already had, then the date window's uncharged cut and the field names it could not read — while keeping an invitation to open an issue. Measured over the 720 shapes a run can end in, 484 of them lost a money sentence or the one instruction a run that delivered nothing owes you, with not a single line over the cut the whole time. Money sentences and your next step now yield last, in their shortest honest form; the ask goes first. Every cause a run can end on also gained a short form of its next step, so the shortening never runs out on the causes whose sentence is longest. No price, input field, output column or charged event changed. ### 1.0.14 — 2026-09-16 - **The input form and the listing now answer the two questions a second run turns on: what a re-run costs, and what a switch costs.** "Reel links" put its promise that a reel Facebook says is gone costs nothing past the point an AI agent’s tool screen cuts the text; it now sits directly after the charge. "Include transcript" and the one-list "Start URLs" door gained worked examples and never-charged sentences in the same window. And the listing’s first screen now says how often a page’s reels actually change and that a re-run is charged only for what is new — a reel already delivered to your account is skipped, with no row and no charge. Nothing about what is collected or charged changes. ### 1.0.13 — 2026-09-16 - **A Facebook page whose link is long is read as a page again, and its reel links still go through as single reels.** Facebook builds an auto-generated address for many pages out of the page's name plus its numeric id, which easily runs past sixty characters — and this actor refused anything longer than that as "not a page or a reel", while telling you to paste a page link, which is exactly what you had pasted. Those pages now work, by name or by link, and so do the ones pasted without `https://`. A long-address page's own video link still goes through the single-reel door, so pasting one collects that one reel rather than ordering the page's whole feed. Nothing was ever charged for the old refusal, and nothing about what is collected or charged changes here. ### 1.0.12 — 2026-09-16 - **A run your own "Max run seconds" stopped no longer reads as the data feed being down.** The last release ended every read at your limit; what it did not do was say what such a read MEANT. A page cut off by your own limit looked exactly like the feed failing, so the row was offered as temporary — nothing charged, please re-run — and the re-run met the identical limit and gave the identical answer. Those rows now say plainly that this run stopped at its own time limit and name it as the setting to raise, on the page walk and on a pasted reel link alike; the run also no longer waits for, or asks again for, a page it has no time left to use. A page the feed really did refuse still reads and behaves exactly as before, and nothing about what is collected or charged changes. ### 1.0.11 — 2026-09-15 - **"Max run seconds" now ends the run, instead of only deciding what the run was allowed to start.** The limit you type stopped the actor from beginning any new work past it — but nothing stopped work already in flight, so a slow page listing, a slow video download or a slow transcript could still be running minutes after your limit had passed, and the run ended late. Each of those legs carried its own separate stopwatch measured from its own start: thirty seconds for a page of reels, forty-five for a reel's video, three minutes for the transcript itself and two minutes for the fallback resolver — so on a short run one transcript alone could outlast the whole limit six times over. Every one of them is now given the smaller of its own limit and the time your run actually has left, and is cut at that. Nothing gets longer: a run with time to spare still gives every leg its full allowance and delivers exactly as before, and a time limit still ends the collecting and never the delivering — reels already in hand are always written out, with the run page naming "Max run seconds" as before. A run that is moved to another machine part-way through now inherits what is LEFT of your limit rather than starting a fresh full one. No price, input field, output column or charged event changed. ### 1.0.10 — 2026-09-14 - **A video link that does not come from Facebook's own servers is now refused before it is fetched, instead of being downloaded, transcribed and charged.** Every media link this actor fetches for a transcript is written by the data feed it buys from, not by you: the reel's video link on a page listing, the SD and HD links on a reel-link lookup, and the format list the fallback resolver prints back. Nothing checked where any of them pointed, so a wrong or tampered answer would have been downloaded from whatever host it named, sent to the speech service and billed to you as a transcript. All four are now checked against Facebook's own media servers first, and a link that is not one is never opened: the reel itself is still delivered, the transcript is uncharged, and the row says the link was refused and names the host — it does not say the reel has no video, because those are two different things. A reel link whose video link was refused but whose Facebook permalink is real still gets the fallback resolver, so nothing that used to produce a transcript stops producing one. No price, input field, output column or charged event changed. - **A run that collected nothing now tells you what to change, instead of only that it collected nothing.** A page name or link this actor could not read ended the run cleanly, so the run page said "Delivered 0 reels of 1 asked for across 0 inputs." and stopped there — 49 characters, no cause and no next step. Two things were wrong. The count of values it could not read was kept on the run's own record and never printed, and so was the count of links that turned out to be ordinary posts with no video in them — so the two likeliest mistakes on this actor named nothing at all. And nothing on the page said what to put there instead. The line now carries both counts, in words rather than internal codes, and on a run that delivered nothing it adds one plain sentence for the biggest cause: the box to use and a working page name to copy, what a page that has posted no reels means, what a reel Facebook says is gone means, why a post with no video in it needs a different link, and which of those a second run would change. A page Facebook would not show us, and a reel lookup that did not come back, are still never reported as "this page has no reels" — neither knows. A run that did deliver is unchanged. No price, input field, output column or charged event changed. - **The store page now shows a real reel row before you spend anything.** The page listed every column and never showed one, so the only way to see what you were buying was to run it. A real delivered row — reel id and permalink, the description as the page wrote it, the post date, the duration, the view count and the page behind it — now sits on the first screen, built by this actor's own parser from a harvested page listing. The signed media links are described rather than reprinted, because they stop working after a few hours. No price, input field, output column or charged event changed. ### 1.0.9 — 2026-09-14 - **A run whose token can read your account memory but not write to it now says so, instead of quietly charging you for the same reels again next time.** The memory that stops you paying twice lives in a key-value store in your own Apify account, and a scoped API token can be allowed to READ it and not to write it — or to write it but not to create it the first time. Such a run looked perfect: it skipped the reels you already had, delivered the new ones, and recorded none of them, so your very next run collected and charged for that whole delivery all over again. The run now says it on the run page, in the run log and on one uncharged row in the dataset, each naming exactly what to grant (key-value store Write, and Create, under Settings → API & Integrations) or the alternative of setting Actor runs to Full access. Runs on a full-access token are unchanged. No price, input field, output column or charged event changed. - **A run started with a limited API token now tells you the repeat check could not run — before it charges you for reels you already had.** The memory that stops you paying twice for the same reel lives in a key-value store in your own Apify account. A run started through the API with a token whose permissions are restricted cannot open it, so every reel you already had was collected and charged again, and nothing said so. That run now says it on the run page, in the run log, and on one uncharged row at the top of the dataset — each naming the permission to grant (key-value store Read, Write and Create, under Settings → API & Integrations) or the alternative, running it from the console. Runs from the console, and API runs on a full-access token, are unchanged: the check runs as before and a reel you already have is still never charged twice. No price, input field, output column or charged event changed. ### 1.0.8 — 2026-09-13 - **A run whose only input is a field name this actor does not have now tells you so, instead of returning sample rows.** If your call put the pages or reel links under a name this actor neither has on its form nor reads as an alternative spelling, the run had nothing to collect and answered with its built-in sample — a successful run, full of reels nobody asked for, which reads as if your call had worked. It now answers with one uncharged row naming the field you sent and the two this actor reads ("Facebook pages" and "Reel links"), the run page says the same thing, and nothing is read from Facebook or charged. A genuinely empty Start, and a Start where you only changed settings, still return the sample exactly as before. Nothing about pricing, the form, the output columns or what gets charged changed. ### 1.0.7 — 2026-09-13 - **A list of links sent under a slightly different field name is now read instead of ignored.** If your call put the reels or pages under a name this actor does not have on its form — `reelUrl`, `url`, `videoUrl`, `postUrl`, `page`, `pageUrl`, `profile`, `username`, `handle`, `startUrl` and a few more — the run used to start with nothing to collect and answer with a note about a field you had never filled in. Those names are now read as the field this actor does use, your lines are collected exactly as if you had typed them in the right box, and one uncharged row tells you the name to use next time. A link sent in both places is still one reel and one result fee. If a line cannot be used at all, the row now names the field you put it in as well as the one this actor reads. Nothing about pricing, the form itself, or the output columns changed. ### 1.0.6 — 2026-09-13 - **Your result limit now holds even when Apify moves the run to another server part-way through.** This actor already picks up exactly where it left off after such a move, and it works out how much of your limit is left from the reels it has already delivered — but it was counting only the reels that carried a fee. A reel your account already has comes back delivered and uncharged, and so does every reel on a run that cannot be billed at all, so those were invisible to the count: the run believed more of your limit was unspent than really was, and could hand you more reels than you asked for. It now counts every reel already delivered to you, whether or not it carried a fee. Nothing about what you are charged moves — a repeat is still delivered without a result fee, and only delivered reels, page lookups and produced transcripts are charged. ### 1.0.5 — 2026-09-13 - **The input schema now speaks to an AI agent as well as to a person.** An agent that finds this actor through Apify's MCP server never opens this page — it reads the input schema. So the schema's own description now opens with the call that works, says what a reel from a page listing costs and what a reel you name by link costs, what a transcript adds and what a 30-reel run with transcripts comes to, lists what is never charged, and names the run option that caps the bill. The Facebook pages field leads with the value shape and an example, then what is never charged, with the console sample instruction last. No price, no charged event, no input field and no output column moved. ### 1.0.4 — 2026-09-12 - **A reel link you pasted is no longer lost to a brief "slow down" from the data feed.** Last build taught a page's reels listing to wait a rate limit or a server error out and ask again; a pasted reel link still gave up within a few seconds and came back as a reel that could not be read this run. A page has a next reel to fill the gap with and a link you named has none, so this build gives the link door the same bounded patience: it waits the refusal out, up to twice per run across all your links together, and only a feed that still refuses afterwards ends in the uncharged "please re-run" row. The waiting is bounded by your run clock and stops at your maximum cost per run, exactly as it does on a page — and a verdict about the reel itself (gone, not a video) is never waited on, because waiting cannot change it. ### 1.0.3 — 2026-09-12 - **A reel link you paste again is no longer charged again.** This actor remembers every reel it delivered to your account, and a page listing already skipped the ones you had. A reel you reached by pasting its LINK did not: the same link billed a full "Reel lookup", and a fresh transcript on top of it, on every run — for a reel your account already held. From this build it is recognised the same way on both doors. The reel still comes back, because you named it: the row lands marked `repeat: true`, with no result fee and no transcript fee, so a schedule or a re-run over the same links costs you only what is new. ### 1.0.2 — 2026-09-12 - **A brief "slow down" from the data feed no longer costs you the rest of the page.** When the feed behind this actor answered with a rate limit, a server error or an unreadable reply part-way through a page's reels, the run used to give up on that page within a few seconds: you kept the reels collected up to that point and the rest of your result limit came back as a walk the feed had cut short. From this build the run waits the refusal out, up to twice per page, and asks for the same batch again; a feed that clears carries on to your result limit, and only a feed that still refuses afterwards ends the walk. The waiting is bounded by your run clock — no wait is taken that the remaining time cannot fit — and it stops immediately at your maximum cost per run. A verdict about the page itself (not found, no reels) is never waited on, because waiting cannot change it. - **A page that really was cut short is unchanged:** the reels already collected are still delivered, and nothing that did not arrive carries a result fee. - **A walk that stopped at one of this actor's own limits now says so in the run's own summary, not just in the row.** Last build the uncharged row learned to say that the 20-page ceiling and the stop on pages that only repeat reels you already have are this actor's bounds and not Facebook's — but the run's summary still filed both of them under the page having posted no reels, so the row and the summary said opposite things about the same page. The summary now names each of them separately, as a stop rather than a miss: nothing ran out, nothing failed, and nothing was charged. "No reels" from now on means only what it says — Facebook's own listing for that page running out. - **A link in your rows never carries a network address.** Every media, thumbnail and profile link this actor delivers goes through our own URL hygiene first, and the address parameter a signed link can carry is removed however the link is written — HTML-escaped, plain or legacy separators, upper or lower case, and inside a link that wraps another link. Nothing else in a link moves: the expiry, the signature and every routing parameter are delivered exactly as they were served. - **A walk that ends short says WHOSE limit ended it, and never denies a fee it already took.** A page listing that runs out is Facebook's own answer and still reads as one; this actor's 20-page ceiling and its stop on pages that only repeat reels you already have now say so in their own words, name the setting that clears them, and state that the page has more reels behind the bound. And any row that closes a walk after reels were already delivered opens with how many were delivered and charged before denying a result fee for the rest. Your inputs, your columns, your prices and every charge on your rows are unchanged, and nothing you have already collected needs re-running. ### 1.0.1 — 2026-09-13 First public build. - A Facebook page — name, slug or link — returns its reels as rows: reel ID, permalink, description, post date, duration, view count, music title, page name and a playable MP4 link. - **A pasted reel link is a first-class input.** `facebook.com/reel/`, `facebook.com/share/r/`, `facebook.com/watch/?v=`, `fb.watch/` and `/videos/` all return that one reel, with its like, comment, share and view counts. - `includeTranscript` adds the spoken words of each reel, charged only on a transcript that was actually produced. A reel longer than 180 seconds is delivered without one, uncharged, and the row says so. - Date filters compare against the reel's own creation time, and reels they drop are never charged. - Your limit is the limit: `maxItems` is read under `resultsLimit`, `limit` and `count` as well, the smallest wins, and one uncharged note row says which name was read. - **An over-ask never refuses the run.** The input schema declares no `maximum` on any number and no `minimum` above 1, so a caller asking for 20,000 rows — or a 5-second run clock — still starts a run: the actor's own ceiling binds (2,000 rows, a 30-3,600 second clock) and one uncharged row says what was asked and what bound it. A schema ceiling is validated by the platform before a container boots, so it returns an error and no run at all — invisible to the buyer and to us.