Jonas K. is a data analyst at a quantitative fund that runs medium-frequency strategies on earnings-related signals. His team's pipeline ingests transcripts automatically, runs NLP models over management commentary, and generates daily rankings. Before earningscalls.dev, they spent more time auditing speaker attribution than building models. We talked about what it takes to run a production pipeline on transcript data and why the JSON format made the difference.
Interview recorded on July 17, 2026. Plans and prices mentioned are the ones the interviewee was on at the time; current plans are on the pricing page.
Jonas, you said the structured JSON goes straight into your pipeline. Walk us through what that pipeline looks like end to end.
Three stages. Ingestion is a scheduled job that polls the recent transcripts endpoint every hour during earnings season. When a new call appears for a ticker in our universe, we pull the full transcript with speaker segments and store it. The cursor-based polling means we never fetch a call twice. It's idempotent by design. That's important for production reliability.
Stage two is feature extraction. We run proprietary NLP models over the executive segments. Sentiment scores, how dense the uncertainty language is, how often they make forward-looking statements, that kind of thing. Because the roles are pre-tagged, we're not wasting compute on operator segments or analyst questions. We filter on executive and process only what matters.
Stage three is signal generation. The features feed into our models, which output daily rankings that portfolio managers use as an input.
What was the breaking point with your previous data source?
Speaker attribution. With our old provider, roughly fifteen percent of segments had the wrong speaker or were unattributed. For a quant pipeline, that's poison. If you're building a sentiment model on management commentary and a chunk of those segments are actually analysts talking, your model is learning from noise. We spent more time auditing attribution than building models.
Earningscalls.dev solved that. The roles are tagged at ingestion: executive, analyst, operator, attendee, shareholder. We filter on executive and move on. The improvement in model performance was immediate and measurable.
How do you handle the freshness requirement? Your signals need to be timely.
New calls land within minutes of the call ending according to the documentation, and in practice that's been accurate. For same-day signals, that's sufficient. We're not trying to trade during the call. That's a different game. We need the transcript by the time US markets open the next morning, and we always have it.
What about the MCP server? You mentioned prototyping with it.
The MCP server was a parallel path. While we were building the hardcoded pipeline, our analysts could query transcripts in natural language through Claude. Things like "What did this CFO say about inventory levels last quarter?" It let them explore the data before the production pipeline was ready. We don't use MCP in production, but during the build phase it helped a lot.
How does the five-year history window affect your backtesting?
It's workable. Five years covers a full market cycle: the post-COVID correction, the 2022 drawdown, the recovery. For medium-frequency strategies, that's enough to validate a signal. If I were running decade-long studies I'd need more, but that's not our mandate. The 2020 start date is a known constraint, and we've designed around it.
What's your request volume look like? Which plan are you on?
Ultra, $39.99. The 20,000 requests cover our polling volume during earnings season, when we're pulling dozens of transcripts per day. During off-season it's quiet. The pricing is predictable, which matters for budgeting. No per-document fees, no surprise overages.
Any advice for someone building a similar pipeline?
Start with the free tier on RapidAPI to prototype. Fifty requests a month is enough to validate your ingestion logic. Then move to a paid plan for production. And use the cursor-based polling. Don't build your own diffing logic. The API gives you the tools to do incremental sync properly. Use them.
What's been the biggest surprise?
How much of the value comes from the structure, not the text. You can get the transcripts elsewhere, sometimes for free. What makes them usable in a pipeline is the speaker segments, the role tags and the consistent JSON schema. Without that, you're spending weeks on parsing and attribution. With it, you're building models on day one.
Want to try the same workflows? You can search a whole sector, pull speaker-tagged transcripts as JSON or connect Claude through the MCP server. Plans and coverage are on the pricing page, and the full reference is in the API docs.