A green run status is not enough to trust an API. I want to inspect the dataset, understand the billing mode and see what happened when a provider or a source misbehaved.
I maintain 15 public Apify Actors at Adaga solutions. The toolbox now links 30 prefilled public tasks covering local-business data, reviews, social profiles, RAG, AI-brand evidence, hotel rate cards, French fuel prices and OpenAPI monitoring.
This is not a claim of 30 customers or 30 universally comparable benchmarks. It is a set of small, reproducible inputs with their outputs and limitations.
Here are five lessons from the recorded runs.
1. A baseline is not a change-detection result
The Stripe OpenAPI example (jW0uxs1wQyafDZjEX) fetched the public Stripe specification and stored a baseline. Its output says exactly that future runs will diff against this version.
It does not prove that Stripe has no breaking changes. That requires a later comparison against a changed specification.
Try the bounded task:
https://apify.com/travelmonitorlab/api-breaking-change-radar/examples/stripe-openapi-breaking-change-watch
2. AI answers need model, prompt and error provenance
A fixed-model Yasha Hotel run (rTzuzBVg0h45cFz3L) measured three answers from recursive/flint-v1.0:free. All three mentioned the hotel. None was marked as citing the official yashahotel.com domain.
Two answers contained one model-provided citation each. That is why total citation URLs and official-domain citations are separate fields.
A second proof (dk1Hi70ELwgSUp01I) compared Adaga solutions and Manus across prompts and models. It preserved three real answers across two models and one provider error. The failed provider call was not counted as a successful answer.
Public dry-run configuration:
https://apify.com/travelmonitorlab/ai-brand-visibility-tracker/examples/brand-p2-multi-model-competitors
These are observations for named models, prompts and timestamps — not universal AI-visibility scores.
3. Preserve source anomalies instead of making the data look tidy
Hotel Rate Monitoring run 7ObEuoyCma8msaGhq fetched Hotel Martha and Hostellerie Val Fleuri from Visit Luxembourg in 3.686 seconds. It returned two cards with zero source errors.
One source labels a suite with minimum 201 and maximum 195. The Actor keeps those values and flags the anomaly rather than swapping them into a plausible-looking range.
Every card includes the source URL, fetch timestamp, HTTP status and HTML SHA-256 hash. The values are published min/max rates, not live availability, date-specific quotes or OTA parity scores.
Real dataset:
https://api.apify.com/v2/datasets/HzYByHb18ia1v9p0T/items
Public task:
https://apify.com/travelmonitorlab/travel-monitor-launch/examples/mersch-luxembourg-published-hotel-rates
4. Validate the resolved business before using review data
A Luxembourg Review Radar run requested Le Bouquet Garni Luxembourg and returned five real review records. The output's resolved place was Restaurant Auberge Gourmande.
That mismatch is useful evidence: a workflow must preserve both query and resolved place, and a human should validate the mapping before assigning reviews to a prospect or sending an alert.
A related five-review report for Esch-sur-Alzette returned clean because none of those five recent reviews was at three stars or below. That says nothing about reviews outside the bounded sample.
Public task:
https://apify.com/travelmonitorlab/review-radar/examples/luxembourg-city-restaurant-review-triage
5. Small outputs are enough to test the contract
A Lyon Maps run returned three restaurants in 45.305 seconds: Carmelo, ART Restaurant Lyon and Maison Moly. That is enough to validate fields and cost before scaling, but it is not a complete market list.
The French fuel example returned 226 station records after filtering Gazole data to departments 69 and 75. The sample station and price are a timestamped snapshot, not a claim about today's cheapest fuel.
The Bubbles Coiffure audit analyzed three reviews and recorded a presence score of 70 in dry-run billing. It is a bounded audit result, not a scientific ranking.
What the 30 public tasks are for
Start with the smallest input, inspect the actual dataset, then decide whether the tool fits your workflow. Technical dry-runs are labelled as such; they skip Actor event charges but not necessarily compute, browser, proxy or external-provider usage.
Catalogue and proofs:
https://adagasolutions.lu/toolbox/
https://adagasolutions.lu/apis/
Source and integration examples:
https://github.com/jeffreyturov-dev/apify-scraping-toolbox
Which acceptance artifact do you inspect first when evaluating an API: the input, one dataset item, the source provenance or the billing events?
Top comments (2)
Keeping the query beside the resolved place is exactly the kind of provenance that prevents a quiet bad join. I’d version the parsing rules too, so a source-format change can be replayed against a saved payload instead of guessing whether the extractor or model drifted. Do you retain raw responses for that replay, or only the normalized records?
Today, Review Radar stores normalized review records and seen-review IDs in a named key-value store. The run input retains the query; each review retains the resolved place, Maps URL and scrape timestamp. It does not retain the raw Maps HTML/responses, so deterministic offline replay is not currently possible.
The Hotel Actor is similar: it stores the normalized card, source URL, fetch timestamp, HTTP status and SHA-256 of the fetched HTML, but not the HTML itself. The hash proves payload identity; it cannot reconstruct the payload.
Your suggested combination — versioned parsing rules plus retained raw payloads with an explicit retention policy — would be the right way to support replay.