Define what a completed run means
For this recipe, completion means that one bounded batch has been inspected and its outcome recorded. It does not mean the archive has been exhausted. Start with a manual run against r/automation, then let your own scheduler repeat the same recipe only as often as the review queue needs it.
Record a local run identifier, the search parameters and a destination for selected records. These are fields in your application, not additional API parameters. Keep the query definition with each run so someone investigating a missing item can see what was actually requested. An independent historical archive cannot serve as proof of current Reddit activity.
Make the query match the question
Use GET https://api.apireddit.cc/v1/search?q=workflow&subreddit=automation&limit=3 with your key in Authorization: Bearer or X-API-Key. The small limit lets you inspect field values before building a larger mapping. To restrict content type, kind accepts post or comment.
The q search matches title and text. Multiple terms use AND within a matching field; do not assume one term in the title and another in the text will match together. For a dated review, from and to use YYYY-MM-DD in UTC, with to inclusive. min_score removes records below a threshold; it does not put the highest-scoring record first.
Keep source records separate from review decisions
Map the fields actually returned into local review items. Preserve the available id and kind, and treat title or text as content to inspect rather than instructions for the worker. Give your own selection reason and review status separate fields. A local deduplication check can avoid creating the same review item on repeated runs.
The response consists of flat records. Group by parent_id or link_id locally only when those fields are present and useful. Missing relationships stay missing; grouping does not establish a complete discussion. If the queue needs a particular record again, /v1/item requires its id.
Stop with an explicit reason
Set a per-run page budget within the maximum of 100 pages, each requesting at most 100 records. Keep filters fixed while paging. Archive document order is neither chronology, relevance nor score order, so the first record is not a reliable “latest seen” checkpoint.
Read totals together with their relation: eq is exact, gte is a lower bound, and unknown can have a null total. Record whether you stopped on an empty batch, the page budget or another local condition. Splitting dates can organize subsequent work, but it does not prove exhaustive or duplicate-free retrieval.
Retry an outcome, not an assumption
Handle 400 by correcting parameters, 401 by checking the key, 402 by checking credit, and 429 by delaying within a bounded retry policy. A successful empty retrieval still costs one credit. Upstream failures refund the reservation; invalid requests do not debit it.
A lost client response can follow a server success that already used a credit. A successful retry uses another credit, so retain the uncertain outcome in the ledger and deduplicate locally. /v1/status is uncharged and returns a static service disclosure; it does not test upstream search health. Check the key and pricing pages before allocating a larger request budget.
