Idealo API Liveness Check - Service Reachability Ping

Make a parameter-free service-liveness request. The documented successful response is {"ok":true}. This endpoint was not included in the supplied live observations, so its response and current availability remain unverified. A successful ping only indicates service reachability. It does not create a product lookup, return listings, verify an EAN match, prove that merchant collection works or establish price freshness. Keep reachability alerts separate from lookup-job failures and legitimate not_found outcomes. Use a product workflow that creates a job and inspects its terminal result when you need collection-level assurance; ping is not a substitute.

API Features

Parameter-free reachability request No product identifier, country, barcode or prior job ID is needed for the documented liveness route.

Minimal documented ok flag The declared success body contains ok:true rather than product or merchant data; this response was not live-observed here.

Independent reachability alert channel Classify a service-liveness failure separately from a completed lookup whose requested product is legitimately not found.

No collection-readiness inference Do not use a passing ping as evidence of working offer retrieval, correct product matching or fresh prices.

Live API Demo

GET /api/project/idealo/ping

No parameters required. Click Query to call the API.

API Response (JSON)

{}

curl -X GET 'https://api.opendata-api.com/api/project/idealo/ping?key=<API_KEY>'

curl -X GET 'https://api.opendata-api.com/api/project/idealo/ping?key=<API_KEY>'

📢

Need Help?

If you encounter API issues or need other API requirements, please contact us.

Use Cases

Collection-window preflight: check documented service reachability before deliberately starting a scheduled set of lookup jobs.
Incident triage: separate a reachability problem from product-specific failures using a liveness signal alongside terminal job outcomes.
Operations status indicator: label the signal as service reachability rather than presenting a passing ping as verified price-data health.
Alert routing design: send connectivity failures to availability monitoring while keeping legitimate not_found observations in the catalog workflow.

Frequently asked questions

Does ok=true prove that merchant offers can be retrieved?

No. The documented flag is only a liveness signal. Collection-level assurance requires creating a product lookup and evaluating its terminal job result, including identity and usable offer data.

Do I need a country or a job ID to call ping?

No. This operation has no product-data parameters and does not depend on a previous lookup. Normal platform API authentication is separate from the endpoint's empty parameter list.

Was the ping response verified in the live checks?

No. The supplied successful observations used the available calls for complete keyword, product-ID and barcode workflows plus a negative search. The ok:true shape is documented, not a live-verified observation.

Should a product not_found outcome trigger a liveness alert?

Not by itself. A completed lookup with not_found is a product outcome, not proof that the service is unreachable. Keep service availability, job execution errors and missing-product observations as separate monitoring categories.

Related operations

Guides

View Subscription Plans →

Check Service Liveness