NASA APOD Scraper
Pricing
from $1.50 / 1,000 result emitteds
Fetch NASA's Astronomy Picture of the Day for any date or date range via the NASA APOD API — title, explanation, image / video URL, HD URL, copyright, media type, date — export to JSON or CSV. A NASA APOD API wrapper; no key needed for small volumes.
DEMO_KEY per source IP, so a spent quota is a
property of the exit, not of the run. The scraper now asks Apify Proxy
for a fresh exit and retries (up to 3 exits) before declaring the quota
exhausted, and proxyConfiguration.useApifyProxy now defaults to true
so every run starts on its own exit instead of the shared Apify egress
every other keyless customer burns. Customer-supplied apiKeys are
metered per key and never rotate. Regression tests use fake sessions.429 OVER_RATE_LIMIT used to FAILED the whole run.
_get_with_retry ignored the Retry-After header entirely and retried a
fixed exponential schedule (capped at 30s) for 5 attempts, then raised
RuntimeError, which propagated uncaught out of scraper.run and failed
the Actor. The shared DEMO_KEY quota (30 req/hour, 50/day) is drawn
against by every customer who never sets their own apiKey — this
Actor's default input (proxyConfiguration.useApifyProxy: false) hits
api.nasa.gov directly from Apify's own IPs, no proxy rotation. A live
probe against the real API confirmed the failure mode: once the quota is
spent, NASA returns 429 with Retry-After: 14609 (~4h) — no retry
schedule inside a single run can wait that out, and the old code burned
all 5 attempts pointlessly before failing loud anyway. Reproduced live
with apify run from a rate-limited local IP: pre-fix, exit_code: 91
(RuntimeError: nasa apod failed after 5 retries); post-fix,
exit_code: 0 with Done — 0 item(s) scraped. NASA API rate limit hit — ..._wait_before_retry honours Retry-After for genuinely
transient throttling, and raises a new QuotaExhaustedError immediately
(no wasted retries) when the requested wait exceeds
RATE_LIMIT_GIVE_UP_THRESHOLD_S (60s) — main.py catches that
specifically and finishes the run SUCCEEDED with whatever was already
pushed plus a status message telling the customer to supply their own
apiKey for a higher, per-customer quota.mode=range no longer requires startDate/endDate up front. Those
fields only carry a Console-UI prefill in input_schema.json, not a
schema default — Apify merges default into API-triggered runs but not
prefill. Any customer calling the Actor via the API with a minimal
payload (including {}, since mode itself defaults to "range") hit
an unhandled ValueError: mode=range requires startDate and endDate.
This was the dominant failure signature behind the 30-day fleet health
check (65% success, 10/29 runs FAILED) — confirmed on the actor's own
account run TyQJkdKvpWpAQg6Rk ({"mode": "range", "count": 5, "thumbsForVideos": true}count days ending today, the same way mode=random
already uses count. A one-sided range (only one of the two dates
set) still fails loud — that's a genuine customer mistake, not a missing
default.