Gong to Structured JSON: The Developer Guide to CRM-Ready Conversation Intelligence
Teams on Gong routinely export their transcripts and call that conversation intelligence. The transcripts go into a folder, or into a notes field nobody queries, and the pipeline value stays the same as before. The actual win, typed JSON fields you can score, route, and measure in CRM, requires one more step that most teams never build.
This guide covers how to get from a Gong transcript to CRM-ready structured output: how to access transcript content via the Gong API, how to apply evaluation Bricks to produce typed scored fields, and how to deliver those fields to Salesforce, HubSpot, or a data warehouse. The result is a pipeline where every Gong call becomes a structured update to the right CRM fields, without rep data entry.
Transcripts are archives, not data
Gong transcripts are unstructured text, whereas CRM opportunity records expect typed fields: a boolean for whether the economic buyer was named, a score for discovery quality, and a string for any competitor mentioned. The gap between the two is why transcript exports don’t survive contact with RevOps workflows. Text files in a shared folder can’t populate a pipeline health report or trigger an automated follow-up task. Only typed fields, with field names that match CRM objects, can do those things.
Storage was never the goal; the point is to convert transcript content into a consistent, typed output with one field per evaluation criterion and a schema that maps directly to the downstream system, which is the contract the rest of the pipeline depends on.
Accessing Gong transcripts via the API
Gong exposes call and transcript content through its REST API, principally two endpoints: GET /v2/calls to retrieve a list of calls with metadata and POST /v2/calls/transcript to retrieve transcript content for a batch of call IDs. Transcripts are returned as speaker-attributed sentence segments, which is the format required for buyer-side evaluation criteria: the evaluation layer needs to know which turns belong to the buyer and which belong to the rep.
The Gong API requires OAuth 2.0 authentication with the appropriate scope for transcript access. For production pipelines, the most reliable trigger pattern is to poll for new calls on a schedule, typically every thirty minutes or hourly, rather than relying on Gong’s webhook support, which has more limited configurability than the polling approach. For historical backfill during onboarding, the same calls endpoint accepts a date range filter and can process the full transcript archive in a batch job.
The call metadata returned by the Gong API includes external identifiers that can be used to link the call to a CRM record. The externalId field, if populated during call ingestion, typically maps to the CRM opportunity or activity ID. For teams that didn’t set external IDs at recording time, attendee email lookup provides a fallback: match attendee emails to contacts in the CRM and find the associated open opportunity.
Applying evaluation Bricks to produce typed fields
Once the transcript content is available, it is sent to the Semarize API with the Kit ID that defines the evaluation schema. The Kit is a versioned group of Bricks, each of which evaluates one criterion against the transcript and returns a typed value: a boolean Brick for "economic buyer named" returns true or false, a score Brick for "discovery quality" returns a number on a defined scale, and a string extraction Brick for "competitor mentioned" returns the competitor name or null. The API call returns a JSON object with one typed field per Brick, typically within a few seconds of submission.
The evaluation schema is designed in advance by mapping from the business question, what do we need to know about this call, to a Brick type and output, to the CRM field that will receive the value. This three-way alignment determines whether the extracted value can be written to the CRM field without a transformation step. Boolean Bricks map to checkbox fields, numeric score Bricks to number fields with the same scale, and categorical Bricks to picklists with matching options, so when the schema is designed to match, the automation layer is trivial.
Kit versioning ensures that the schema doesn’t change silently. Once a Kit version is deployed to production, the field names, types, and valid values are fixed. Changes to the evaluation logic require a new Kit version, which means CRM field mappings and reporting models aren’t broken by an upstream change. The schema stability post covers why this matters for production pipelines where call scores need to be comparable over time.
Delivering output to Salesforce, HubSpot, or a data warehouse
The validated extraction output is a JSON object with the call’s CRM opportunity ID and one typed field per Brick. Writing it to Salesforce is a PATCH to the Opportunity object using the field API names. Writing to HubSpot is a PATCH to the Deal object using the property names. Both follow the same pattern: look up the record by the CRM ID attached to the call, confirm the record is in the right stage to receive an update, and write each field value to its corresponding field.
For teams writing to a data warehouse alongside the CRM, the same JSON output can be routed in parallel to a BigQuery, Snowflake, or Databricks table. The Kit version is included as a column in the warehouse table so historical scores can be filtered by evaluation version when the schema changes. The conversation data warehouse post covers the specific schema patterns for each warehouse platform.
Gong and Semarize as complementary layers
Gong provides recording, transcription, and a rep-facing coaching layer, while Semarize provides the structured extraction and scoring layer on top of that transcript content. The two outputs serve different consumers: Gong’s analytics feed the coaching dashboard and rep-facing call review, and Semarize’s typed JSON feeds the RevOps data layer, CRM enrichment, and any downstream automation that needs to reason about call content programmatically. Using both avoids having to replace the recording platform to get structured output, and it means the teams that already use Gong can keep the workflows they have while adding the data infrastructure layer they are missing.
The Gong API alternatives post covers the specific gap between what the Gong API returns and what RevOps workflows require, and how Semarize fills that gap without replacing Gong.
Semarize evaluates Gong transcripts against a customer-defined schema and returns typed JSON ready for CRM enrichment, warehouse analytics, and RevOps automation.
Common questions
Do we need to use the Gong API, or is transcript export enough?
For low-volume or one-off processing, manual transcript export from the Gong UI is sufficient to test the evaluation pipeline. For production use, the Gong API is the right approach: it delivers transcripts programmatically, includes call metadata needed to link the output to the right CRM record, and allows the pipeline to run automatically after each call without manual intervention. The API also supports historical backfill via date-range filtering, which is useful for processing the existing call archive during onboarding.
How does the Semarize pipeline handle calls where the transcript quality is poor?
Bricks that can’t find sufficient evidence for a criterion in the transcript return null rather than guessing. Null values on key fields are informative: they typically mean either the topic wasn’t discussed on that call, or the transcript quality wasn’t sufficient for the evidence to be identifiable. The automation writes null to the CRM field only when it should override a previously populated value, and otherwise leaves the existing field intact. This means the CRM retains the best evidence from any call in the deal rather than being overwritten by a null from a poorly transcribed call.
Can the same Semarize Kit be applied to transcripts from other sources as well as Gong?
Yes. The Kit schema is independent of the transcript source. The same discovery Kit applied to a Gong transcript and a Zoom transcript of a comparable call evaluates the same criteria and returns the same field types. Teams that use multiple recording platforms, Gong for enterprise calls and Zoom for others, can apply the same Kit across all sources and get comparable structured output without separate schema definitions or extraction pipelines per source.
Where should the structured output land first: CRM or warehouse?
For most RevOps teams, the CRM is the higher-priority destination because that is where pipeline decisions and workflow triggers live. Writing to the CRM opportunity record first ensures the structured fields are available for automation, forecasting models, and rep-facing views as soon as a call is processed. Writing the same output to a warehouse table in parallel adds the analytical layer without delaying the operational use case. Both destinations receive the same JSON payload from the extraction step, so routing to both adds only the cost of a second write, not a second extraction.
Continue reading
Read more from Semarize
Gong Captures the Transcript. Here’s What It Can’t Score.
Gong’s scoring runs against a fixed model — you can’t attach your product documentation, rate card, or qualification playbook to its evaluation layer. For four evaluations that matter — product accuracy, pricing audit, methodology A/B testing, and deal readiness scoring — knowledge grounding and KB isolation are the only architecture that works.
CRM Enrichment From Sales Calls: The RevOps Data Ops Playbook
Most CRM enrichment stalls at 30% field coverage because the output is unstructured - reps updating from memory, summaries stored as notes. The fix is a structured extraction pipeline: transcript to consistent fields to CRM to automation triggers. This playbook covers the schema, the routing, and the implementation in Salesforce and HubSpot.
Conversation Intelligence for Developers: Don't Build a Fragile Pipeline, Don't Buy a Black Box
Most teams don't fail to add conversation intelligence because the model is bad; they fail because the integration is fragile and unstructured. The fix isn't a better LLM pipeline or a platform API you can't control. It's a layer that takes a transcript, runs it against a versioned Kit, and returns deterministic typed JSON you can test, version, and route into your product.