Retrieve Job Status and Product Results
View all Idealo Product Search & Merchant Offers API endpoints →Pass the fresh job_id returned by a keyword, ID, barcode or URL lookup. No durable example job ID is provided: results are retained for one hour after completion. The documented lifecycle is pending followed by completed or failed, with results empty while pending. Poll at a spaced interval, for example starting around five seconds, and apply backoff, a deadline and a total-call budget. A lookup needs at least one creation call and one retrieval call; extra polls add network calls without guaranteeing earlier completion. Observed completed responses contained error, job_id, status, source, operation, country, created_at, done, total, summary and results. summary included found, not_found, error and classifications. Each result row carried query, status and result. For ID and barcode lookups the found result included product identity, price summaries, offers and fetched_at. Keyword lookup instead returned listing summaries with offers=[]. A single-term job had done=1 and total=1 but 36 found result rows, so these counters do not measure the number of distinct listings. Top-level error:false and status:completed do not mean a product was found. The verified nonsense-term job completed with done=1, total=1, summary.found=0, summary.not_found=1, summary.error=0 and one row with status:not_found and result:null. Item errors and failed jobs are separate documented outcomes; inspect both job status and every result status. When an item supplies errorCode, correct invalid_query rather than blindly retrying it, and bound any retry policy for other codes. Collect and store usable snapshots with the requested country, query, operation and product fetched_at before the job expires. created_at describes job creation, not the product observation time. Nullable fields are not zero, false or empty strings. This endpoint retrieves temporary job output; it does not provide a historical-price archive. An unknown or expired ID has a documented Job not found response, but that error branch was not live-tested.
API Features
Live API Demo
🔒 Sign in to try it live
Log in to call this API with your own API key. New accounts get 100 free credits — no card required.
Log in / Sign upNo active API key found. Create one in your Dashboard, then reload this page. Dashboard →
/api/project/idealo/get-job API Response (JSON)
{} curl -X GET 'https://api.opendata-api.com/api/project/idealo/get-job?key=<API_KEY>&job_id=<job_id>'
Query Result
Use Cases
- Bounded polling worker: persist active job IDs, schedule spaced retrievals and stop at a terminal state or application deadline.
- Pipeline stage coordinator: release selected listing-ID enrichment only after discovery has produced reviewed found results.
- Negative observation ledger: preserve terminal not_found outcomes instead of converting missing products into zero-priced inventory.
- Timestamped price store: collect usable terminal product observations before expiry and build your own dated history without assuming an archive endpoint.
Frequently asked questions
Can a completed job still mean the product was not found?
Yes. The observed nonexistent-term job had error=false and status=completed, yet its sole item was not_found with result:null and summary.not_found=1. Test each result status before reading a product or price. Job completion is not a product-match guarantee.
How often should I poll, and how long can I keep a job ID?
Use a spaced interval such as five seconds as a starting point, with backoff, a deadline and a total-call budget rather than a tight loop. Results are documented to expire one hour after completion. Fetch and store terminal output in that window; saved example IDs are not reusable controls.
Why can done and total be 1 while there are many results?
The counters describe processing of the single submitted value. One keyword may match multiple listing rows: the verified iphone 16 job had done=1 and total=1 with summary.found=36. Do not interpret total as the number of listings or merchants.
Does retrieving the job give me historical prices?
No. It gives temporary output for that lookup. Build history by saving repeated approved observations with country, listing identity and product fetched_at. Keep created_at as the separate job-creation time, and preserve null fields rather than filling them with invented values.
How should item errors and missing job IDs be handled?
A documented item error can occur inside a completed job; a failed job is a separate outcome. If an item reports invalid_query, fix the input instead of repeatedly resubmitting it. Bound retries for other errors. Unknown or expired job IDs are documented to return Job not found; that branch and failed-job payloads were not live-verified.