IndexNow API for Developers: Bulk URL Submission at Scale

Why one-URL-at-a-time doesn't scale

Submitting a single URL through a dashboard works fine for an occasional blog post. It stops working the moment you're shipping a product catalogue, a job board, a directory, or any programmatic-SEO site that adds or changes hundreds of URLs a day. At that volume, a human clicking "submit" per page isn't a workflow, it's a bottleneck — and every page that sits in the queue behind it is a page search engines don't know exists yet, which for a fast-moving site can mean weeks of lost visibility on content that's already live and already losing potential traffic. Bulk submission through an API turns that from a manual chore someone has to remember into a call your own publishing pipeline makes automatically, the moment content actually changes, with no person in the loop at all. Teams that skip this step almost always discover the gap the hard way: a launch goes out, traffic from paid channels looks fine, and organic search traffic simply never shows up for pages that were technically live the whole time — because nothing ever told search engines those pages existed in the first place.

What "bulk" means over IndexNow specifically

IndexNow is a shared protocol: Bing, Yandex, Seznam.cz, and Naver all consume submissions from the same endpoint, so one accepted request reaches all four at once instead of requiring four separate integrations, four sets of credentials, and four different request formats to maintain. Google does not participate in IndexNow — there's no bulk-submission equivalent for it today, so a well-formed sitemap and Search Console's URL Inspection tool remain the right tools for Google specifically, and any claim that a tool "instantly indexes on Google" through IndexNow is describing something that isn't technically possible. IndexLaunch's API sits in front of the shared IndexNow endpoint: it handles the key-file hosting and the underlying protocol details for you, and gives you one authenticated HTTP call that fans out to every engine IndexNow actually reaches, so your integration code only ever has to talk to one place.

The request and response

A submission is a single POST with your API key and an array of URLs:

POST https://indexlaunch.site/api/v1/submit
Authorization: Bearer il_live_xxxxxxxxxxxxxxxxxxxxxxxx
Content-Type: application/json

{
  "urls": ["https://example.com/page-1", "https://example.com/page-2"]
}

A successful call returns how many URLs were accepted and their internal tracking IDs, so you can look each one up later against your dashboard's submission history:

{ "submitted": 2, "ids": ["j57...", "j58..."] }

Authentication and errors

Every request needs a live API key in the Authorization header, generated from your account settings and scoped to the domains you've verified ownership of. A missing or invalid key returns 401; a key that's valid but not authorized for the domain you're submitting returns 403; a malformed request body — not valid JSON, or a urls field that isn't an array of strings — returns 400. All three are worth handling explicitly in your integration rather than treating every non-2xx response the same way and silently retrying, since the fix for each is completely different: rotate the key, check domain ownership in your account, or fix the payload shape before resending. Logging the response body on failure, not just the status code, makes debugging a broken integration far faster than guessing from the status alone.

How a batch submission actually reaches every engine

What a submission does — and doesn't — guarantee

Acceptance means the search engine has queued your URL for a sooner crawl, not that it's indexed instantly the moment the API call returns. Most submissions clear the queue in 2 to 6 minutes, but each engine still applies its own relevance and quality judgment before a page actually shows up in results — bulk submission fixes discovery speed, it doesn't fix thin content, a noindex tag left on by mistake, or a page that genuinely doesn't merit ranking. It's also worth resubmitting a URL any time its content meaningfully changes, not only the first time it's published; IndexNow was built specifically for that re-notify use case, and a stale product price or an outdated article left unsubmitted after an edit is a missed opportunity as much as a brand-new page is. Treat a rejected or ignored submission as a signal worth investigating rather than noise: it often points at something concrete, like a robots.txt rule accidentally blocking the path, a key-file mismatch, or a redirect chain the crawler gave up following.

Which package actually gives you API access

API access starts at the Professional package (3,500 credits, priority crawl queue), moves up to Enterprise (5,000 credits, the fastest available turnaround) for higher submission volume, and the Agency package (10,000 credits) is built specifically for running the API across several client sites from one account rather than juggling separate logins per client. Every credit works the same way through the API as it does through the dashboard: one credit submits one URL, there's no separate metering for programmatic access, and any submission still stuck pending after 7 days refunds its credit automatically with no support ticket needed — so a flaky third-party crawl on the receiving end never quietly costs you anything. The Starter tier deliberately doesn't include API access at all, on the reasoning that a site small enough for a $50 starting package is also small enough to submit its handful of URLs through the dashboard by hand without missing anything.

Wiring it into your deploy pipeline

The highest-leverage place to call the API isn't a manual batch job run occasionally, it's your existing publish or deploy step: a CMS webhook firing on "post published," a post-deploy hook that diffs which pages actually changed in that release, or a nightly job that resubmits anything updated in the last 24 hours as a safety net for anything the webhook missed. That turns indexing into a byproduct of shipping content rather than a separate task someone has to remember to do — the same way a CI pipeline runs tests automatically instead of waiting for a developer to remember to run them by hand before every release. Once it's wired in once, it keeps working for every future page without any further attention. Rate-limit the calls sensibly on a very high-frequency site — batching several changed URLs into one request rather than firing one request per URL — since a single call already accepts an array, and there's no benefit to a hundred single-URL requests over one hundred-URL request that does exactly the same job with a hundredth of the network overhead.