An investment research API gives you the same access to financial information that an analyst gets from a terminal, a filings database, and a browser, except it returns structured, cited output that another program can consume. Many stop at retrieval: you ask for a ticker's fundamentals, you get fundamentals. The harder problem is the work that happens after retrieval, when someone has to read forty sources, reconcile them, and produce a document a director or CIO will put in front of a client or use to make a multi-million pound decision.
The second half is what deep research APIs automate. This article covers seven workflows that run in production today on the Valyu Search and DeepResearch APIs. All of them are built for investment research and banking deal teams, all invocable with a single call and a company name, with every result traced back to the primary source.
TL;DR: the seven workflows
| # | Workflow | workflow_id |
What it answers |
|---|---|---|---|
| 1 | Company Profile | ib-company-profile |
What does this company do, how does it make money, what happened recently? |
| 2 | Comparable Companies | ib-comps-analysis |
Who are the real peers, what are they trading at, why does each belong? |
| 3 | Precedent Transactions | ib-precedent-transactions |
What has been paid for assets like this, and under what circumstances? |
| 4 | DCF Valuation Reference | ib-dcf-reference |
What assumptions should a DCF use, and what does the market imply? |
| 5 | LBO Screening Analysis | ib-lbo-screen |
Could a sponsor buy this, and would the returns work? |
| 6 | Buyer & Investor List | ib-buyer-list |
Who would buy this, and why would each one care? |
| 7 | Strategic Alternatives Review | ib-strategic-alternatives |
What paths are available, and what does each one cost? |
What is an investment research API?
Teams use investment research APIs to build equity research tools, power AI agents, run screening pipelines, and replace manual data collection.
They fall into three categories, and the distinction matters more than any vendor comparison:
- A market data API answers "what is NVDA's EV/EBITDA."
- A web data API answers "what does this specific 10-K say."
- A research API answers "build me a defensible peer set for NVDA and explain why each comp belongs in it," a question with no single endpoint behind it.
Many production stacks use all three.
The gap between those question types is measurable. Across 4.2 million queries logged through the Valyu DeepResearch API, a single user-facing research question expands, on average, into 11 to 19 sub-queries. An investment thesis request expands into 14 to 22. A market data API serves one of those sub-queries in milliseconds. A research API is the thing that decides which nineteen to ask, runs them, and reconciles the answers.
The seven workflows below sit in the third layer and assume you already have the first two.
The 7 investment research workflows (DeepResearch)
These are ordered the way a deal team actually builds a pitch. Profile first, valuation next, then the strategic layer on top.
1. Company Profile
The question it answers: What does this company actually do, how does it make money, and what has happened to it recently?
Every deal document starts here, which makes it one of the most repeated tasks on any deal team. Someone needs a clean business overview, segment breakdown, revenue composition, management summary, and recent developments assembled from filings, transcripts, and news, with sources attached.
task = valyu.deepresearch.create(
workflow_id="ib-company-profile",
workflow_params={"company": "NVIDIA (NVDA)"},
output_formats=["markdown", "pdf"],
deliverables=["docx"],
)
result = valyu.deepresearch.wait(task.deepresearch_id)
What comes back: A structured pitch book profile covering business description, segment and geographic revenue split, financial summary, competitive positioning, and a recent-developments timeline. Every claim cites its source.
When to use it: Pitch prep, first-call decks, target screening, onboarding a new coverage name. It is the entry point most teams run first, and the input to most of the others.
2. Comparable Companies
The question it answers: Who are the real peers, what are they trading at, and why does each one belong in the set?
Comps are where analyst judgment and grunt work collide. Pulling multiples is trivial. Defending the peer set is not, and that is the part that gets challenged in a client meeting.
task = valyu.deepresearch.create(
workflow_id="ib-comps-analysis",
workflow_params={"company": "Datadog (DDOG)"},
deliverables=["xlsx"],
tools={"code_execution": {"enabled": True, "max_calls": 5}},
)
Enabling code_execution matters here. The agent computes the multiples and statistics rather than reproducing numbers it read somewhere, which removes a whole class of transcription error.
What comes back: A peer set with trading multiples (EV/Revenue, EV/EBITDA, P/E), the selection rationale for each name, and summary statistics across the set. The xlsx deliverable drops straight into a model.
When to use it: Valuation sections, fairness work, any time you need a peer set you can defend line by line.
3. Precedent Transactions
The question it answers: What has been paid for assets like this, and what were the circumstances?
Precedent transaction analysis is unusually painful to automate with conventional tools, because deal terms are scattered across press releases, merger proxies, and trade press. Multiples paid are frequently not stated and have to be derived.
task = valyu.deepresearch.create(
workflow_id="ib-precedent-transactions",
workflow_params={"sector": "Enterprise search and observability software"},
search={"start_date": "2019-01-01"},
deliverables=["xlsx"],
)
The input here is a sub-sector, not a ticker: "Vertical SaaS for healthcare", "Defense electronics", "Specialty insurance brokers". Narrow enough to define a deal set, broad enough that a deal set exists.
The search.start_date parameter is doing real work. Precedents from a different rate environment are actively misleading, and constraining the window is usually the right call. Read it as a bound on which documents get retrieved rather than on which deal dates reach the output: a 2019 floor will still surface a 2015 transaction if a recent source discusses it.
What comes back: A transaction table with acquirer, target, date, deal value, multiples paid, and the strategic context of each deal.
When to use it: Sell-side positioning, board valuation discussions, establishing a defensible premium range.
4. DCF Valuation Reference
The question it answers: What assumptions should a DCF on this company actually use, and what does the market imply?
This workflow does not replace your model. It builds the reference layer underneath it, the assumption set you would otherwise spend a day sourcing and defending.
task = valyu.deepresearch.create(
workflow_id="ib-dcf-reference",
workflow_params={"company": "Airbnb (ABNB)"},
tools={"code_execution": True, "charts": True},
deliverables=["xlsx"],
)
What comes back: Revenue growth and margin assumptions with sourcing, a WACC build with component inputs, terminal value approaches, and sensitivity ranges. Charts if you enable them.
When to use it: Before you build the model, and again when someone challenges an assumption and you need the provenance.
5. LBO Screening Analysis
The question it answers: Could a sponsor actually buy this, and would the returns work?
A fast structural read on whether a target is financeable. Debt capacity against cash flow, likely structure, sponsor fit, and whether the returns clear a hurdle without heroic assumptions.
task = valyu.deepresearch.create(
workflow_id="ib-lbo-screen",
workflow_params={"company": "Ziff Davis (ZD)"},
tools={"code_execution": {"enabled": True, "max_calls": 8}},
deliverables=["xlsx"],
)
What comes back: Debt capacity analysis, indicative capital structure, cash flow coverage, sponsor fit assessment, and a returns feasibility view.
When to use it: Sponsor coverage, take-private screening, deciding whether a name is worth full diligence.
6. Buyer & Investor List
The question it answers: Who would buy this, and what is the specific reason each one would care?
Buyer lists are where generic AI output fails most visibly. "Large technology companies" is not a buyer list. A useful one names specific acquirers and articulates the strategic logic per name: adjacency, gap being filled, precedent for similar deals, and capacity to pay.
Its target is free text rather than a ticker, which matches how a sell-side mandate usually arrives. The client is private, so you describe the asset (profitability, scale, category) and the buyer universe follows from that profile rather than from a name.
task = valyu.deepresearch.create(
workflow_id="ib-buyer-list",
workflow_params={"target": "A profitable $200M ARR HR-tech SaaS"},
deliverables=["xlsx", "pptx"],
)
What comes back: Segmented strategic and financial buyer universe with per-buyer rationale, acquisition history, and capacity assessment. The pptx deliverable is built for the sell-side kickoff deck.
When to use it: Sell-side mandates, pitch materials, board discussions about who the natural acquirers are.
7. Strategic Alternatives Review
The question it answers: What are all the paths available to this company, and what does each one cost?
The only heavy mode workflow in the set, running close to 40 minutes at $2.60 against $0.50 for a standard run. The extra depth goes into evaluating sale, IPO, recapitalisation, and standalone paths, then comparing them against each other rather than assessing any one in isolation.
Mode is defined by the workflow itself, so you do not pass it. ib-strategic-alternatives runs heavy by default.
task = valyu.deepresearch.create(
workflow_id="ib-strategic-alternatives",
workflow_params={"company": "Peloton (PTON)"},
previous_reports=[profile_task_id, comps_task_id],
deliverables=["docx", "pptx"],
)
The parameter worth noting is previous_reports. It chains earlier workflow output into this one, so the strategic review reasons from the profile and comps you already ran instead of rediscovering them. It accepts up to three prior task IDs.
What comes back: Each alternative assessed with valuation implications, execution risk, timing, and stakeholder considerations, plus a comparative recommendation.
When to use it: Board advisory, activist defence, any mandate that begins with "what are our options."
Checking a run before you pay for it
This is the workflow where it pays to look before you spend. At close to forty minutes it is the longest run in the set, and the failure mode you care about is not a bad answer. It is a good answer to a question you did not ask.
workflows.preview() resolves a workflow against your parameters and returns exactly what would run, without starting a task and without spending anything.
preview = valyu.workflows.preview(
"ib-strategic-alternatives",
workflow_params={"company": "Peloton (PTON)"},
)
print(preview.resolved.mode) # "heavy" - budget accordingly
print(preview.resolved.input) # the fully substituted prompt
print(preview.resolved.research_strategy) # sources and methodology
print(preview.resolved.report_format) # structure of the output
print(preview.resolved.deliverables) # files that will be produced
resolved is a ResolvedWorkflowTemplate with six fields: input, research_strategy, report_format, deliverables, mode, and tools. For the strategic alternatives review that surfaces mode: "heavy" and a docx plus xlsx pair, which is what determines the cost in time and money.
Preview also validates. Pass a parameter the workflow does not define and it fails immediately, rather than at task creation:
valyu.workflows.preview("ib-buyer-list", workflow_params={"company": "Confluent (CFLT)"})
# success: False | error: 2 validation errors <- key is "target", not "company"
valyu.workflows.preview("ib-buyer-list", workflow_params={"target": "Confluent (CFLT)"})
# success: True
Because preview costs nothing and returns instantly, it is the one control that composes with a parallel batch, which is where the next section picks it up.
Production patterns
Constrain sources deliberately. search.search_type accepts all, web, or proprietary. For workflows that must not cite blog speculation, restrict to proprietary. source_biases lets you weight sources from -5 to +5 rather than excluding them outright, which is usually the better instrument.
Pin versions in production, float in staging. Workflows are in beta and templates improve. Pin workflow_version anywhere a parser depends on the shape of the output.
Preview before you spend. workflows.preview() is free, instant, and catches a malformed parameter set before it becomes a billed run. Make it the default pre-flight in any pipeline. It is the cheapest control you have over a process that otherwise runs for half an hour before telling you anything.
Inspect the template, do not guess at it. workflows.get(slug) returns the typed variables, so you can check the parameter name and whether it is required before wiring anything up. preview() goes further and shows the resolved mode, which is what tells you whether to budget twelve minutes or forty.
detail = valyu.workflows.get("ib-strategic-alternatives")
for variable in detail.workflow.variables:
print(variable.key, variable.required)
check = valyu.workflows.preview(
"ib-strategic-alternatives",
workflow_params={"company": "Peloton (PTON)"},
)
print(check.resolved.mode) # heavy - budget accordingly
print(check.resolved.deliverables)
Track long runs by status, not by blocking. deepresearch.status(task_id) returns a DeepResearchStatus: queued, running, completed, failed, and cancelled, plus paused and awaiting_input if you have enabled a checkpoint, alongside the cost and the generated deliverables. Tag each task with metadata at creation and you can reconcile a whole batch afterwards without holding six threads open.
Structured output for pipelines. Pass a JSON Schema object in output_formats when the consumer is a database or dashboard rather than a person. Use deliverables when the consumer is a banker who wants an XLSX.
Chaining them: the full pitch-book pass
The workflows are individually useful and considerably more useful composed. A complete first-pass pitch book on a single target:
import concurrent.futures
COMPANY = "Snowflake (SNOW)"
# Each workflow declares its own variable key - comps and buyer list take
# "target", precedent transactions takes "sector".
FOUNDATION = [
("ib-company-profile", {"company": COMPANY}),
("ib-comps-analysis", {"target": COMPANY}),
("ib-precedent-transactions", {"sector": "Cloud data warehousing and analytics"}),
("ib-dcf-reference", {"company": COMPANY}),
("ib-lbo-screen", {"company": COMPANY}),
("ib-buyer-list", {"target": COMPANY}),
]
def run(item):
slug, params = item
task = valyu.deepresearch.create(
workflow_id=slug,
workflow_params=params,
workflow_version=1,
deliverables=["xlsx"],
metadata={"deal": "project-frost", "slug": slug},
)
return valyu.deepresearch.wait(task.deepresearch_id)
# Free pre-flight: validate every parameter set before anything is billed
for slug, params in FOUNDATION:
check = valyu.workflows.preview(slug, workflow_params=params)
if not check.success:
raise ValueError(f"{slug}: {check.error}")
results, failed = [], {}
with concurrent.futures.ThreadPoolExecutor(max_workers=6) as pool:
pending = {pool.submit(run, item): item[0] for item in FOUNDATION}
for future in concurrent.futures.as_completed(pending):
try:
results.append(future.result())
except Exception as exc: # keep the five that worked
failed[pending[future]] = exc
# Strategic review reasons over everything above
strategic = valyu.deepresearch.create(
workflow_id="ib-strategic-alternatives",
workflow_params={"company": COMPANY},
previous_reports=[r.deepresearch_id for r in results][:3],
deliverables=["docx", "pptx"],
)
On a recent full pass against Snowflake, the six parallel standard runs completed in 26 minutes, the fastest at 12, the slowest two at 25 and 26, since the batch only finishes when its slowest member does. The heavy strategic review added a further 39. Total wall clock was a little over an hour, total cost $5.80, and the output was seven cited documents in formats a deal team already works in.
Budget by the slowest workflow rather than the average. If you need a faster first look, run the foundation six and start reading those while the strategic review finishes. Nothing downstream blocks on it except the review itself.
Note workflow_version=1 pinned explicitly, and metadata tagging every task with a deal code. Both are small habits that pay for themselves the first time you need to audit what produced a number.
Collect results with as_completed rather than pool.map. map re-raises the first exception when you iterate it, so a single failed run discards the five that succeeded, after you have already paid for them and waited 26 minutes. Gathering failures into a dict instead lets you retry the one that broke.
What changes for deal teams
The honest framing is not that these workflows replace analysts. They collapse the retrieval and first-draft phase of work that currently occupies the first days of every mandate.
We have the numbers on what that phase costs. Looking at six months of financial query traffic across 4.2 million API queries, a single investment thesis run resolves in about 75 minutes of agent time at roughly $50, against 14 to 18 analyst hours for the equivalent output, work a junior analyst would take three to five days to produce.
The seven workflows in this article are the productised version of that same pattern, scoped tighter. The same dataset shows where this is already concentrated. Traditional research (investment theses, filings, and transcripts) accounts for 57% of query volume, and 74% of sell-side queries fall into that bucket. These are not speculative use cases. They are the majority of what financial research traffic already looks like.
The analyst's job moves to where it should have been: challenging the peer set, pressure-testing assumptions, and forming the view. The workflows handle the part that was never judgment in the first place.
Frequently asked questions
What are the three types of investment research API?
Market data APIs return structured numeric series. Web data APIs return raw page content. Research APIs return synthesised, cited analysis built from many sources. Most production stacks use all three, because each answers a question the other two cannot.
How is a deep research API different from a market data API?
A market data API answers questions with a schema behind them, like a ticker's EV/EBITDA, in milliseconds. A deep research API answers questions with no single endpoint behind them, like building a defensible peer set with rationale, by running multi-step research across many sources over several minutes.
What are the 7 investment banking workflows in Valyu?
Company Profile, Comparable Companies, Precedent Transactions, DCF Valuation Reference, LBO Screening Analysis, Buyer & Investor List, and Strategic Alternatives Review.
Can I create my own workflows?
Yes. Custom workflows are defined with a slug, title, and version containing a prompt, research strategy, report format, and typed variables with key, label, and required fields. They appear in workflows.list() alongside the Valyu-published catalogue.
How do I discover available workflows programmatically?
Call valyu.workflows.list(scope="valyu", vertical="investment-banking"). The scope filter selects between Valyu-published and your organisation's own workflows; vertical filters by industry category.
What output formats are supported?
output_formats accepts markdown, pdf, or a JSON Schema object for structured output. deliverables generates files in csv, xlsx, pptx, docx, or pdf. Structured output suits pipelines; deliverables suit humans.
Are the outputs cited?
Yes. Every claim carries citations to source documents, which is what makes the output usable in regulated and client-facing contexts rather than only for internal exploration.
Can workflows build on each other?
Yes. previous_reports accepts up to three prior task IDs, so a downstream workflow reasons from earlier output rather than rediscovering it. Chaining the profile and comps into the strategic alternatives review is the common pattern.
How do I keep output stable as workflows improve?
Pin workflow_version in production. Version 1 continues returning the same structure after the template is revised, so downstream parsers do not break when a prompt improves.
Top comments (0)