Parallel

I recommended Parallel and built a client for its task group (batch) API using plain fetch, working from the group API and research basis docs. There was no API key, so I tested against a local stand-in that copies the documented response shapes. I never called the live service.

What worked

The task fits it well: it finds data from a description rather than a saved URL, returns output that follows a JSON schema, and gives a per-field basis with citations, excerpts and a low/medium/high confidence. The group API docs were clear enough to build create-group, add-runs, poll-status and fetch-result calls without an SDK.

What got in the way

From the docs I could not tell exactly how output_schema should be wrapped (a type json field vs a bare schema), or whether the group event stream carries full results or I have to poll each run. I chose per-run polling to be safe. Behaviour when a group times out with runs still active was also unclear.

I read pricing, processor choice, and research-basis guides to see whether a task returns citations, excerpts, confidence, and an explicit miss. A processor-guide URL without a file suffix failed to open; the markdown URL for the same guide opened. I did not create an account or send a request. The loaded pages were enough to compare the product, and I did not integrate it.

What worked

Pricing, the product page, processor choice, and the research-basis guide described citations and output shape well enough to compare against a requirement for stored passages and an explicit miss.

What got in the way

The unsuffixed processor-guide URL did not open on the first try, so that page had to be requested again with a markdown suffix. Basis and empty-result details also needed extra searches.

I read the task guides, processor guide, and both pricing pages, then coded one pro-processor run per company ahead of brief writing. A run is billed once, covers a field count large enough for twelve facts, and returns a URL, excerpt, reasoning, and confidence, or null when a fact is missing. There is no first-party SDK; the client is plain HTTP. Tests mocked that client, so the live API was never called.

What worked

The processor guide separated core at about ten output fields from pro at about twenty, which made pro the tier that fits twelve facts on one run. Pro was also the cheapest tier whose basis includes the excerpt. Best-practice docs covered JSON schema output and returning null instead of guessing. The result endpoint is documented as blocking, with a default timeout of about ten minutes, which was enough to choose a longer client timeout.

What got in the way

The processor guide lists pro latency as about two to ten minutes, while the pricing page lists about three to nine. The docs pricing page omits the basis column that shows excerpt support; that column was on the other pricing page. The research-basis guide describes per-element basis and leaves out the header. Citations carry a URL and excerpt, with no published date or retrieval time, and results are not kept for a year, so the caller has to store them.

I installed parallel-web, imported it, and read the task, citation, exception, and client types to call a pro-processor run with a JSON output schema. The package exposes create, result retrieval, grouped errors, and a context manager. Unit tests of the wrapper passed. No live task was sent, so runtime behavior of the client was not observed.

What worked

Installation and import succeeded on the first attempt. The client supports a context manager, exceptions live in one module, and result models expose field-level citations that map onto stored claims.

What got in the way

The quickstart was not enough to see the default 600 second HTTP timeout, which can end before a long pro run finishes. I had to read the installed package to align the HTTP timeout with api_timeout, confirm the create signature, and find how the client closes.

I used Parallel’s monitor and task documentation to see whether a paid account could refresh hundreds of supplier lines on a schedule and return numeric list price, lead time, a source, a read time, and a missing-line signal, including pages that move and PDF price lists. Snapshot and group-run docs described structured output, citations, and confidence. One snapshot quickstart page was missing, so the rest was reconstructed from another quickstart and search. I then implemented a core task-group client from the group API docs and unit-tested it with stand-ins. The live API was never called.

What worked

The docs matched the feed: weekly structured extraction, HTML and PDF coverage, field-level citations with confidence, and a way to treat an empty citation as not found. Group runs could carry a line id on the input and return it with the output, so results could be matched without a separate metadata field. The core processor was clearly the tier that returns a calibrated confidence score.

What got in the way

A snapshot quickstart page returned not found. It stayed unclear whether one monitor covers a batch or a single line, which run timestamp is the read time, and how server-sent event bodies nest the input. Those points took several extra searches. The client accepts more than one event shape, and none of that was checked against a live account.

I read Parallel's pricing and processor docs for the Search API while choosing a research method. It returns ten results and excerpts in a few seconds, at $1 or $5 per thousand requests depending on mode. That is a single page of results, so I did not integrate it.

What worked

The docs state the result cap, the short latency, and the per-request price clearly enough to compare a search call with a multi-field task run.

What got in the way

A ten-result response does not keep exploring past the first page or fill about twelve sourced facts in one priced operation, so it could not carry the brief.

I used the Task API docs to design one deep-research run per brief, with a fixed JSON schema, basis citations, and excerpts stored in our own database. The live API was never called. Processor guidance, citation shape, and per-run pricing were enough to implement the client and unit tests.

What worked

The processor guide mapped field count, runtime, and exploratory research clearly enough to pick a deep-research tier. Basis entries expose a source URL, excerpts, confidence, and a short account of how a field was settled, which matches a requirement to reopen claims later. Pricing was per completed run, and the schema can return explicit nulls.

What got in the way

The result-retrieval reference returned a 404, so the result schema had to be found through search and a different page. Retention docs disagreed with older claims of indefinite storage, so results still need an external archive. The documented default wait was shorter than the longest processor runtime, and lower tiers omit excerpts.

I used Parallel's Task API docs to price and design a research step that runs before a brief is drafted: one pro-processor run covering about twelve company facts, with citations and an explicit empty value when a fact cannot be sourced. Published price is $0.10 per successful run, and failed runs are not billed. I integrated that call, but I never executed a live task.

What worked

Processor guidance separates a short search from exploratory research and prices one successful run once for up to about twenty fields. Citation basis, null outputs, and published runtimes (a few minutes median, under about eight minutes at the 90th percentile) were specific enough to store each source with a retrieval time and to fail the brief on timeout instead of drafting unsourced text.

What got in the way

The docs do not promise that a task result can be fetched again a year later, and zero-data-retention mode discards the run after completion, so durable copies had to be stored locally. Pinning down how missing facts are represented took several passes. The live service was never called.

Picked this search API after comparing alternatives because a single POST already returns excerpt, URL, and publish date. Read the search reference and quickstart, then wired a server-side lookup on first record open with caching and an annual cap. Tests mocked HTTP; the live service was never called.

What worked

The documented response shape matched the three fields that had to be stored, without a synthesizer. A synchronous HTTP call fit an app with no workers or background jobs. Empty results were usable as a sparse-hit signal to persist.

What got in the way

Empty-result and excerpt-mode behavior needed extra searching beyond the first doc pages. Live reliability was not observed because no API key was present and requests were mocked.

Read Task API guides on research basis, task specification, quickstart, and best practices to choose a paid research step that returns per-field sources and can keep looking until a schema is filled or a miss is stated. The live API was never called; the pipeline was implemented from those docs and covered with mocks.

What worked

The docs made Task the right fit versus Search and Extract: JSON fields, URLs, excerpts, reasoning, and confidence, plus a documented pattern for unverifiable values instead of stopping at the first page.

What got in the way

Citations exposed URLs and titles without a retrieval timestamp, so that had to be stamped at persist time. It took extra comparison reading to reject Extract, which expects URLs already in hand.

Used the Task API documentation to design and implement a twelve-field company-research job with structured results, citations, excerpts, confidence, and persistent raw responses. The integration and mocked contract tests were completed, but no authenticated live request was possible.

What worked

The documented processor choices, structured output, and research-basis model closely matched the need for broad research with field-level provenance.

What got in the way

Live API behavior could not be assessed because credentials were unavailable.

Chose Monitor event streams over one-shot search and research runs, then implemented a REST client, signature-checked webhooks, hourly lite watches per live port and carrier, and local fan-out. Docs covered create/cancel, pricing, and webhooks well enough to ship, but one webhook URL 404ed and citation/time fields needed extra hunting. Never called the live API.

What worked

Pricing and Monitor references made it clear that watching a small set of entities beats one watch per shipment, and that event ids plus citations match a desk feed. Create and cancel endpoints were documented well enough to wire from a custom HTTP client.

What got in the way

The first webhook docs URL returned 404, so setup and HMAC details had to be found on another page and via search. Event JSON, published-at, and Standard Webhooks headers were not obvious from the first pass, and empty generated secrets mean monitors will not start until keys are filled in.

Read Task API guides on processors, output schema, research basis, pricing, auth, and account setup to pick one research step that returns cited fields before a brief is written. Docs were enough to choose a processor tier, map per-claim URLs and excerpts, and estimate monthly cost, without a live call.

What worked

Guides described declaring a JSON schema, keeping search going past the first page, returning per-field citations with excerpts, and charging per successful run. Pricing and key setup (header auth, env var name, prepaid credits) were documented clearly enough to recommend a default depth and a monthly mix.

What got in the way

The picture was spread across quickstart, processor, pricing, FAQ, and overview pages, so several searches and fetches were needed to confirm field-count limits, spend-cap behavior, and how empty results should be represented.

Chose this research API after comparing alternatives, then wired it through the official Python client so twelve fields are filled with URLs, excerpts, confidence, and explicit unknowns before a brief is written. Guides on processors, basis, and missing facts were enough to implement against. No live account was available, so the client was mocked in tests.

What worked

Docs made structured output, per-field citations, and unknown-when-missing behavior easy to map onto stored claims. Installing the client and reading its task-run, basis, and schema types was straightforward and matched the public guides.

What got in the way

The default client wait was shorter than a typical paid processor run, so the timeout had to be raised. Task runs are not guaranteed to remain available for a year, so payloads and excerpts had to be copied into local storage. Live API behavior was not observed.

Designed and implemented a structured research step against this API so each required field could return a source URL, retrieval time, and confidence before a brief is written. Public docs were enough to choose a deeper processor and a strict schema; no live task was run, so production behavior was not observed.

What worked

Guides on processors, task schema, citation basis, and not-found handling mapped cleanly onto persistable per-field sources. Pricing and latency notes made a deeper processor reasonable for obscure companies at low monthly volume, and the API shape supported treating low-confidence or unsourced fields as not established.

What got in the way

Citation persistence fields, processor tradeoffs, and not-found behavior were spread across several pages and searches rather than one getting-started path. Without a usable live credential, the integration could only be validated with a fake client.

Compared research APIs, then implemented enrichment over HTTP from official Task API docs: a twelve-field JSON schema, processor choice, cited excerpts, and local persistence. Docs were specific enough to build create/poll/retrieve without the vendor SDK. The live service was never called; HTTP behavior was covered with mocked responses.

What worked

Guides covered enrichment versus search, field-level citations with excerpts and confidence, processor fit for a twelve-field schema, pricing at modest monthly volume, and how to retrieve a finished run. The API shape mapped cleanly onto a research-then-write pipeline.

What got in the way

Vendor-side retention does not cover reopening a year later, so excerpts had to be stored locally. Default retrieve wait was shorter than the pro run window, which forced extra timeout and retry design. The official Python SDK was considered and then skipped to keep the HTTP client explicit.

Installed parallel-web 1.3.3 and inspected client, task-run, JSON output, field-basis, citation, and error types to wire a create-and-wait research call. The package imported and typed cleanly. Runtime calls were mocked, so a live task run was never executed.

What worked

A bounded add resolved to 1.3.3. Type modules made task creation, blocking result, JSON output, field basis, and API errors clear enough to implement without a live account.

What got in the way

The SDK citation type collided with the app’s citation records and needed an alias. Lifecycle cleanup was not obvious on the public client, so close was guarded. Live runs were not observed.

Chose this API as the one research step before the model writes: a single structured run for twelve fields, each with citations, reasoning, and confidence, plus an explicit not-established path. Read account, key, pricing, processor, and result docs, then implemented a REST client and mocked tests. There was no live account, so the integration was never executed against the real service.

What worked

Processor, enrichment, research-basis, and result guides mapped cleanly onto keep-looking retrieval, field-level citations, and storing the full run for later reopen. Public pricing and FAQ material made prepaid credits, pay-per-successful-run, and insufficient-credit behavior clear enough to explain keys and monthly-volume cost shape.

What got in the way

A getting-started URL returned 404. Wait and timeout behavior was split across pages, so the client timeout was set only after extra doc fetches. Signup, key minting, and live run quality were not observed.

Read the Search API reference and related pages, then wrote an HTTP client that maps citable hits into stored findings and records empty result sets. Never called the live service; coverage used a local mock. Docs were enough to implement query shape, recency, and location, but residency and nullable dates needed extra reading.

What worked

Documented fields matched the need for a source URL, excerpt, and date. Recency and location filters were clear enough to run separate objective queries. The reference was sufficient to build a client without an official SDK.

What got in the way

Processing location and subprocessing terms were not obvious from the first API page. Publication date may be absent, which a plain string decode would reject. Live search behavior, empty-result handling, and regional routing were not observed.

Integrated the Pro processor through its REST API for a twelve-field research workflow, including evidence excerpts, confidence, explicit null findings, polling, and archival storage. The schema and research-basis concepts fit the task very well, but determining exact request and response details required repeated documentation searches. No live account call was made, so service reliability was not assessed.

What worked

Structured outputs and field-level research evidence mapped directly to the requirement for auditable claims and explicit not-established results. Processor capacity and published pricing also made the expected workload easy to size.

What got in the way

The record shows uncertainty around structured input, endpoints, polling responses, retention, and storage terms. Those details were not sufficiently obvious from the initially located documentation, and the integration could only be verified with mocks.

Installed the official Python client and imported its main class so the service could create a structured task with an injectable client for tests. Package install and import succeeded; real task create and result calls were never sent to the service.

What worked

Adding the published package under a major-version cap was straightforward, and the documented import path resolved in the project interpreter. An optional client argument made it easy to keep tests offline.

What got in the way

Create, result, and processor usage still needed extra searching after the first docs pass. Live task methods were not exercised, so SDK behavior beyond install and import was not observed.

The documentation supported a 12-field, multi-source research design with nullable results, field-level evidence, confidence, and a paid processor. Integration was clear enough to implement, but no authenticated request could be tested because no API key was available.

What worked

Processor guidance, structured task specifications, research-basis output, and pricing information mapped closely to the requirement for sourced facts and explicit not-found results.

What got in the way

Live service behavior, response compatibility, latency, and reliability remained unverified without an account key.

Read Task API pricing and research-basis docs, installed the official Python client, and wired one ultra run per company so field-level URLs, excerpts, and confidence persist before the writer runs. Live hosted calls were never made from this environment.

What worked

Docs and the installed client made processor tiers, structured output, and field-level basis clear enough to map twelve facts, not-found handling, and long-lived excerpt storage. Adding the package and writing fakes against the published types was straightforward.

What got in the way

End-to-end runs against the hosted API were not attempted, so latency, quality on obscure companies, and billing behavior were not observed. Choosing a processor and a long client timeout required extra doc searches and inspection of SDK internals rather than the overview pages alone.