Changelog

Narration plays over the scenes. voiceUrl lays an audio file you already have across the whole video, at a voiceVolume you choose. SpiderVideo never generates the speech. A voice that cannot be downloaded, or that carries no audio, fails the job instead of rendering a silent video.

The music gets out of the way. duckMusic drops the music about 12 dB while the voice speaks and restores it in the pauses. It needs both musicUrl and voiceUrl, and it stays off unless you ask for it. The dip starts shortly before each phrase, so the first word is never buried.

Captions burn in, word by word. captions takes word tokens carrying a startMs and an endMs, and highlights each word across its own span. They are drawn exactly as timed, and nothing listens to the audio, so a caption is only as accurate as the timings you send.

Agents can drive all three. The create_video tool carries the new fields from @spideriq/mcp 1.93.0 and @spideriq/mcp-leads 1.17.0. Older installs dropped them without saying so, so upgrade before asking an agent for a voiceover.

Every bulk lead now reaches your CRM. Enrichment results are written to your normalized lead store as they complete, whatever the run was sourced from. This is source agnostic: a purchased list, an uploaded file, and a re-run over leads you already own all land the same way.

Past bulk runs were backfilled, so nothing is stranded. Runs submitted before this change were reprocessed into the same store rather than left behind. An older run now reads exactly like a new one, which makes an empty result a signal worth checking rather than something to expect.

Directory fields arrive on four of the six sources. Agency listings, CSV uploads, JSON uploads, and re-runs over your own leads now carry team size, services, sectors, awards, clients, languages, and verification status. Google Maps sources carry none of them, because Maps does not publish them.

The upload column mapper offers all 30 fields. The mapping panel listed 15 of the fields the API accepts, so a header like Mitarbeiterzahl could not be pointed at team size by hand. It now renders the server's own list, and takes a Google place ID as an identifying column.

`?format=llm` and `?format=json` no longer return 422. 94 of the 114 endpoints that accept a format parameter refused one or both of the two values the platform documents. All 114 now take json, yaml, md and llm, and each still answers with its own content type rather than quietly falling back to JSON.

One vocabulary instead of fifteen. Fifteen files each hand-declared their own list of permitted formats, so every new endpoint was free to invent a sixteenth. A single shared definition now owns every format parameter in the API, and a build check fails if a route hand-rolls its own again.

Invalid values still fail loudly. ?format=bogus remains a 422 carrying a structured error that names the parameter and the values it would have accepted. This release widened what is accepted, never what is ignored: an unsupported format is still refused rather than silently answered in JSON.

Pick a past run and enrich what it missed. Choose any earlier campaign or a single job inside it, and I show you two numbers: how many leads it matched, and how many would actually gain from the stages you picked. A run whose websites are already crawled has nothing to gain from another crawl, and the second number says so.

Filter your whole corpus like a spreadsheet. A condition and group filter over 84 fields, including city, category, and whether a website or an email is present, with both counts updating as you type. "Select all N in these results" sends the filter, not a list of rows, so the server re-runs the same question at submit time and the answer cannot drift.

Your agent can drive it without a chat box. The field catalogue now serves the filter grammar itself, so a Claude or Cursor agent reads the operators, builds a valid filter, and submits it. Six CLI commands and seven MCP tools cover the same path.

Counting eligible leads got fast enough to be interactive. Restoring anti-join planning took a 10,065 candidate tenant from 10,934 ms to 20 ms, and a tenant of roughly 206,000 businesses from past the query timeout to 450 ms. Measured with EXPLAIN on the live corpus, August 2026.

A finished bulk run now tells you what it did. GET /jobs/{job_id}/results returns a populated payload for every completed bulk run. It previously answered success with no data at all, which was indistinguishable from a run that had genuinely found nothing.

Zero kept is an answer, not a silence. The screening block reports how many records arrived, how many survived your filters, and why the rest were dropped. A run that kept nothing because your own review floor rejected every record now says exactly that.

The leads live on the child jobs, and the parent hands you their ids. A bulk parent is a funnel summary, never a list of businesses. children.job_ids gives you the per-lead job to read each result from, so there is no route left to guess at.

The run reports its own spend. A cost block travels with the results, so what a run cost sits beside what it delivered instead of somewhere else.

Apify is a second provider. Pick it in the source dropdown and it runs a Google Maps actor, billed per record. Its estimate returns a real dollar figure before you commit, so the cost of a run is something you read rather than discover.

Bring your own records. Upload a CSV or JSON file of businesses you already have and run them through the same enrichment chain. There is no provider and no spend at the source, so you pay only for the stages you switch on.

CSV columns are mapped, not guessed. Upload a file with any headers and I propose which column holds the name, the address, the phone. You confirm or change that, and the run stays blocked until at least one identifying column is mapped.

A finished run tells the truth. Results now carry enriched_count and not_enriched_count, a run still working reports enriching instead of claiming it is done, and a run whose enrichment produced nothing reports failed rather than completed.

Many searches, one purchase. Every search term runs against every location inside a single provider job. I deduplicate the flat result set on the provider's own record key, so a business that two searches both find is bought and enriched once.

Results read exactly like a campaign's. Each deduplicated lead runs the same website scrape, email verification and VayaPin chain. The response carries the same 24 business fields a campaign returns, so every export and parser you already have reads bulk output unchanged.

Two spend guards run before anything is bought. A run is capped at 25,000 records, and your rolling 24 hour spend is checked up front. Submitting writes a manifest and returns straight away, so a refused run costs nothing at all.

A confirmation screen for the money. The dashboard multiplies your terms by your locations by your record limit and shows the total before you commit. Leave that limit blank and each search buys 500 records, which is the setting that surprises people.