This week's update is all about reliability. We shipped three fixes across our Amazon, YouTube, and Google Scraper APIs, all aimed at the same goal: making sure the data you pull from Scrapingdog is accurate, complete, and consistent every single time you call it. Here's a rundown of what changed and what it means for your workflows.
Amazon Search API & YouTube Channel API: Back to 100% Success Rate
If you've been running scraping jobs against Amazon product listings or YouTube channel data over the past few weeks, you may have noticed the occasional dropped request or inconsistent response. We tracked this down to intermittent errors affecting both the Amazon Search API and the YouTube Channel API, and we're glad to report that both have now been fully resolved.
Both endpoints are back to a 100% success rate. In practice, this means:
- Fewer retries needed on your end. If your pipeline had built-in retry logic to handle occasional failures from these endpoints, you should see that logic triggering far less often, which translates into lower latency and fewer wasted API calls.
- More predictable job completion times. Batch jobs that pull large volumes of Amazon product data or YouTube channel metadata should now complete more reliably without unexpected gaps in the dataset.
- Cleaner downstream data. Whether you're feeding this data into a pricing model, a competitor-tracking dashboard, or a content analytics tool, you can now trust that missing or malformed responses won't be introducing silent gaps into your results.
We know that API reliability is one of the most important factors for anyone building production workflows on top of scraping infrastructure, especially at scale. Intermittent failures are often the hardest kind of bug to catch, because they don't show up in every test run, only under certain conditions or load patterns. Our engineering team spent time isolating the root cause on both endpoints separately, since Amazon and YouTube are scraped through different underlying mechanisms, and confirmed the fix by running high volumes of test requests against both before rolling it out. If you were previously working around these intermittent errors with custom retry or fallback logic, this is a good time to revisit that logic and simplify it.
Google Search API: Goto Links No Longer Appearing in Ad Results
The second fix this week addresses a more subtle issue in our Google Search API. Some ad results returned by the API were including unexpected "Goto" links mixed into the response. For anyone parsing ad data programmatically, these extraneous links could throw off downstream logic, whether that's ad performance tracking, competitor ad monitoring, or SERP feature analysis.
This has now been fixed. Ad results returned by the Google Search API are cleaner and more consistent, without the unexpected Goto links showing up where they shouldn't. If your integration had any filtering or cleanup logic specifically built to strip out these stray links, you should be able to simplify or remove that step going forward, since the API response itself is now returning the expected structure.
This kind of fix matters most for teams running large-scale SERP monitoring or ad intelligence workflows, where even small structural inconsistencies in the response can cascade into inaccurate reporting if left unchecked. We appreciate the reports from users who flagged this, since edge cases like this are often easiest to catch from real-world usage patterns.
Google Scraper API: Missing Address Field in Local Results, Fixed
The third fix in this release targets local search results returned through our Google Scraper API. We identified an issue where the address field was missing for some local search results, meaning downstream consumers of that data were left without a key piece of location information they needed.
Addresses are now correctly included in the API response for local results. This is especially relevant if you're using our local search data for:
- Local SEO tracking, where address accuracy matters for verifying business listings.
- Lead generation workflows, where a missing address can break enrichment pipelines that depend on location data.
- Competitive local market analysis, where you need complete and consistent business details across every result in a dataset.
This fix is tagged as v1.0.1, reflecting a versioned update to the local results schema. If your integration has any null-checking or fallback logic for the address field, you can now expect that field to be reliably populated for local results going forward.
Here is a video tutorial about our weekly updates.
What This Means for You
None of these fixes require any changes on your end, they take effect automatically. But if you've built workarounds for any of these known issues (retry logic for Amazon or YouTube calls, filtering for stray Goto links in Google Search ads, or fallback handling for missing addresses in local results) this is a good moment to review and streamline that code now that the underlying issues are resolved.
As always, reliability improvements like these are part of our ongoing commitment to making sure Scrapingdog's APIs are something you can build production systems on with confidence. We'll keep shipping fixes like this regularly, and we'll keep you posted here each week with what's changed.
Have feedback on any of these APIs, or run into an issue we haven't caught yet? Reach out to our support team, we read every report.
