Make.com pagination jak načíst všechna data z API

Narazil jsi na situaci, kdy tvoje Make.com API volání vrátí jen prvních 100 záznamů, ale ty víš, že jich v systému je tisíc? Přesně takhle funguje Make.com pagination, a pokud ji neošetříš, tvůj scénář tiše zpracuje jen zlomek dat, aniž bys o tom věděl.

Sám jsem s tím strávil hodiny. Každé API má trochu jiný přístup ke stránkování, dokumentace je často skoupá na příklady a správné nastavení smyčky v Make není vždy zřejmé. Tahle zkušenost mě nakonec přiměla sestavit toolkit s hotovými patterny, ale o tom až na konci.

Co je pagination a proč ho API používají

Představ si databázi s milionem záznamů. Kdybys je najednou vytáhl všechny, server by se pod tou zátěží zhroutil a odpověď by ti přišla za minuty. API proto data rozdělují do stránek, vrátí třeba 50 nebo 100 záznamů najednou a k další dávce tě odkážou přes token, offset nebo číslo stránky.

To je v pořádku, dokud to jako Make.com scénář umíš zpracovat. Pokud ne, dostaneš jen první stránku a zbytek ti unikne.

Typy paginace v Make.com scénářích

Než začneš stavět smyčku, potřebuješ vědět, s jakým typem stránkování pracuješ. Většina API používá jeden ze tří přístupů.

Offset pagination je nejstarší a nejrozšířenější. API bere dva parametry, offset (od kolikátého záznamu začít) a limit (kolik jich vrátit). Každou iteraci zvyšuješ offset o hodnotu limitu, dokud nedostaneš méně záznamů, než je limit. To znamená, že jsi na poslední stránce.

Page-based pagination funguje podobně, ale místo offsetu posíláš číslo stránky. API vrátí stránku 1, pak 2, pak 3. Ukončovací podmínka je buď totalPages v odpovědi, nebo prázdné pole výsledků.

Cursor pagination používají modernější API, Graph API od Mety, Notion, Airtable. Každá odpověď obsahuje next_cursor nebo next_page_token, speciální klíč, který předáš do dalšího volání. Smyčka běží, dokud cursor nepřijde prázdný.

Jak nastavit pagination v Make.com krok za krokem

Základní struktura je vždy stejná: smyčka s proměnnou, která si pamatuje stav, HTTP modul, který volá API, a router nebo filtr, který rozhodne, jestli pokračovat.

1. Nastav si Data Store nebo proměnnou

Potřebuješ někde uchovávat aktuální offset nebo cursor mezi iteracemi. Nejjednodušší je použít Make.com Variables modul nebo Data Store pro trvalejší uložení.

2. Sestav HTTP požadavek s dynamickými parametry

V HTTP modulu předáš offset nebo cursor jako query parametr. Místo pevné hodnoty tam vložíš referenci na proměnnou ze smyčky:

{{1.offset}}

Pro cursor pagination to vypadá takto:

{{if(1.next_cursor; 1.next_cursor; "")}}

3. Nastav Repeater nebo smyčku přes Router

Make.com nemá nativní „while loop”, ale pagination se dá elegantně řešit přes kombinaci Repeateru a podmínkového routeru. Repeater spustí iteraci, po každém API volání zkontroluje, jestli odpověď obsahuje další stránku, a pokud ano, Repeater se spustí znovu s upraveným offsetem.

4. Definuj ukončovací podmínku

Tady lidé nejčastěji chybují. Ukončovací podmínka musí být přesná:

• Offset pagination: length(items) < limit
• Page-based: currentPage >= totalPages
• Cursor: isEmpty(next_cursor)

Bez správné ukončovací podmínky smyčka buď skončí předčasně, nebo pojede donekonečna a spotřebuje všechny tvoje operace.

Časté chyby při načítání stránkovaných dat

Zapomenutý reset proměnné. Pokud scénář běží opakovaně a offset si pamatuješ v Data Store, musíš ho na začátku každého běhu vynulovat. Jinak začneš od místa, kde jsi skončil minule.

Špatná ukončovací podmínka pro poslední stránku. Pokud API vrátí přesně limit záznamů i na poslední stránce, podmínka length < limit selže. Vždy ověř, jak konkrétní API signalizuje konec dat, někdy je to has_more: false, jindy prázdné items: [].

Ignorování rate limitů. Při paginaci voláš API rychle za sebou. Pokud nemáš mezi iteracemi pauzu, API tě může throttlovat nebo dočasně zablokovat. Přidej Sleep modul s pauzou 1-2 sekundy, pokud API rate limit dokumentuje.

Neošetřená chyba při přerušení. Co se stane, když API při třetí stránce vrátí chybu? Scénář se zastaví a ty nevíš, kde přestal. Dobrý error handling s uložením posledního úspěšného offsetu ti ušetří opakované zpracování od začátku.

💡 Pro testování nastav limit na velmi malé číslo, třeba 2-5 záznamů, ať smyčku otestuješ na malém datasetu bez spotřebování stovek operací.

Hotové patterny pro rychlé řešení

Popisovat obecné principy je jedna věc, ale každé API je trochu jiné a sestavit funkční smyčku od nuly trvá. Dělal jsem to znovu a znovu na různých projektech, pro Airtable, HubSpot, Notion, různá interní API, a pokaždé začínal od stejného bodu.

Proto jsem sestavil Make.com API Pagination Toolkit, kolekci hotových blueprintů pro nejčastější typy paginace. Stáhneš, importuješ do Make, přemapuješ proměnné podle svého API a máš funkční scénář za minuty.

Pokud hledáš také jak pracovat s iterátory v Make.com pro zpracování vrácených polí, oba patterny se přirozeně doplňují.

Stáhni API Pagination Toolkit na Gumroad, hotová řešení pro offset, page-based i cursor pagination.

Závěr

Make.com pagination není složitý koncept, ale detaily, které rozhodují o správné funkci smyčky, jsou neočividné, správná ukončovací podmínka, reset proměnných, ošetření rate limitů. Jakmile to jednou pochopíš a máš funkční pattern, aplikuješ ho na jakékoliv API za pár minut.

Pokud nechceš trávit hodiny debugováním, toolkit ti dá hotový výchozí bod, ze kterého stačí přizpůsobit proměnné. A pokud řešíš také práci s datem a časem v Make.com, jsou to oblasti, kde přesnost detailů rozhoduje úplně stejně.