TL;DR
- Bombora Intent API is the first evaluation when a team wants company-level topic research and needs to manage and retrieve intent signals programmatically. Ask for the precise Company Surge fields, observation window, account coverage and contract permissions you will receive.
- G2 Buyer Intent data via the G2 API is a stronger fit when software-marketplace activity, product profile, category, comparison or pricing research, is relevant to your product. Its data reference publishes fields such as company ID, domain, visit type, date, last seen and buying stage. Signal access is tied to a subscription for each G2-listed product.
- 6sense APIs fit an organization already using 6sense for account identification, segments or predictive scoring. The API family and credits are not one generic intent feed: company identification, firmographics and Lead Scoring have different tokens and consumption rules. The company-identification endpoint uses a credit for each matched response.
- Do not buy “API access” as a vague line item. Get a sample payload, endpoint or delivery method, documented history and update cadence, rate/credit limits, account identifiers, permitted storage and a replay test in writing before the contract.
- The original shortlist included Common Room as if its API exported signals. Its current documentation says the public API is for data into Common Room, not data out. It may be a useful destination or orchestration layer, but it does not meet this particular buyer requirement as documented.
What counts as an intent API?
An intent-data API gives an authorized application machine-readable access to signals that can be joined to accounts and acted on. That is a narrower claim than “we integrate with Salesforce” or “we have an API.” A product may offer a dashboard, a native CRM connector, a webhook into its own platform and a private partner API, yet offer no outbound endpoint for the account signal your data team expects to retrieve.
Start with the question the automation must answer. A software vendor may want to know whether a target account has compared its product with a competitor on G2 in the last seven days. A manufacturer may want accounts whose research on a group of industrial topics has risen above their normal baseline. An existing 6sense customer may want its account score inside a custom prioritization service. All three are called “intent,” but their source, grain, timestamp and rights differ. Treating them as one numeric field creates false equivalence.
The shortlist below is for a team building a repeatable feed into a warehouse, CRM task queue or account scoring model. It does not rank the accuracy of the vendors: no controlled cross-vendor coverage benchmark was run. Each recommendation turns on a different observed environment and a specific, documented access path. Buyers still need their own contract to establish exact endpoints, entitlements and limits.
Three options compared
| Option | Evidence you are buying | Documented interface | Main procurement trap |
|---|---|---|---|
| Bombora Intent API | Elevated company-level research on chosen business topics | Developer portal describes signal management and access to intent data | “Company Surge” does not mean a named person researched or intends to buy; confirm your report fields and reuse rights |
| G2 Buyer Intent API data | Product/category/pricing/comparison activity on the G2 research network | Public Buyer Intent data dictionary lists account, visit and stage fields | Access depends on the subscribed G2 product and signal types; data is not a universal web intent feed |
| 6sense APIs | Company identification, firmographics and/or 6sense predictive scores in the subscribed environment | Official API overview and token/credit documentation | Endpoint-specific tokens and credits; the scoring API has an edition gate |
No single row is “the best API” for every buyer. The first two are materially different third-party research sources. The third is a way to use an existing ABM and predictive-scoring investment programmatically. An organization needing raw, timestamped article views should not assume that a topic surge or derived account stage satisfies its event contract.
1. Bombora Intent API
Bombora's developer portal describes an Intent API for defining and managing signals and accessing intent data. Its Company Surge product is based on businesses consuming more content about a topic than they usually do, as described in Bombora's customer resource centre. That is useful if you sell a solution associated with stable topic groups and want to prioritize accounts whose research has changed. It is not a record of someone clicking your own site or a declaration of a budget.
For a GTM build, ask the vendor to provide the actual payload for ten accounts and three topics. The important fields are company/domain identifier, topic or cluster ID, current score or surge measure, comparison baseline, observation window, generated time and geography or segment if licensed. Determine whether the feed returns every account, only accounts above a threshold, or a report you request. A score of 70 without a defined scale and window is difficult for a seller to use.
Test topic selection as carefully as the API. “Cloud security” might pull a very different population from “identity governance,” and a broad topic can produce a large, expensive list of accounts that your reps cannot act on. Map topics to your products and negative examples before choosing thresholds. Keep fit separate: a company can have intense topic research and still be too small, outside the territory or an existing customer with another owner.
Bombora is a weaker fit if the buyer needs to know that an account compared two specific software products yesterday, or wants a direct visitor event from its own site. Its strength is relative topic demand at company level. The API contract must say what data may be stored, how long it may be retained and whether it may be combined with other sources or surfaced to sellers. Do not infer those rights from the existence of a developer portal.
2. G2 Buyer Intent API data
G2's Buyer Intent data reference, updated in September 2026, is unusually concrete. It lists product_id, company_id, company_domain, visit_type, visit_date, last_seen, total_page_views, activity_level and buying_stage, among other fields. Visit types include product profile, category, compare, alternatives, pricing and competitive activity. A data team can design a warehouse table and acceptance tests against those fields before purchase.
Interpret the grain correctly. The reference explains that total_page_views can be a daily total for the same company, region and page, while last_seen is the most recent visit to that page that day. This is not necessarily one row per anonymous human action, and it does not name the visitor. Preserve the page type and URL instead of reducing every record to intent = high. Pricing-page research, category exploration and competitor comparison can justify different review tasks; none proves a signed purchasing process.
G2's Buyer Intent documentation says the plan determines the available signals and that each G2-listed product needs its own subscription for Buyer Intent. It also says the research set includes G2, Capterra, Software Advice and GetApp. Do not assume your product's category has the same volume as a popular software category, or that an agency with three listed products gets one pooled subscription. Ask for a historical sample by product, geography and signal type.
G2 is a strong fit for software companies whose buyers research on those marketplaces and whose sales motion can act on account-level comparisons. It is a poor fit for an industrial category with little marketplace activity, or a team seeking broad off-site topic research. Ask exactly which dataset and authentication you will receive, how far back it goes, whether the API returns all subscribed events or only filtered insights, and how often it refreshes. The public dictionary is a schema, not a commercial entitlement.
3. 6sense APIs
6sense's API overview lists Company Identification, Lead Scoring, Company Firmographics and Firmographics & Scoring APIs. These are valuable to a company already running 6sense segments and predictive models: a custom web or CRM workflow can retrieve a company and its scoring context rather than reimplementing the model. It is not the same as buying a general-purpose off-site research-event stream.
The 6sense token and credit documentation matters more than a generic “API available” checkbox. Tokens are provisioned at the organization level for the APIs the organization has bought. The Lead Scoring token requires a Predictive or Advanced subscription. Company Identification consumes one API credit per matched company response, and repeated identification of the same IP can consume additional credits during the contract year. Firmographic and enrichment APIs draw on a different 6sense credit pool. When allocated credits run out, the Company Identification API stops by default unless an overage setting is enabled, and additional use is billed under the agreement.
This changes architecture. If a site widget calls Company Identification on every page load, repeated matches may burn credits without adding new account evidence. Cache or deduplicate within the rights and freshness allowed by the contract, and size the budget against expected calls, not just unique companies in CRM. If the use case is a nightly account-score refresh, confirm the specific scoring endpoint and its package rather than assuming a visitor-identification token works for it.
6sense is a strong fit where its account graph and score already inform sales. The non-fit is purchasing an enterprise ABM platform solely because an API is available when the team only needs one narrow event feed. Ask the account team to document API access, annual credit allotment, overage price, score refresh, published segments and the sample response for your use case.
What was removed from the shortlist
Common Room can combine useful first-party, community and partner signals, but its API/Zapier documentation explicitly says the API is for getting data into Common Room, not getting data out. It is therefore misleading to recommend that public API as an outbound buyer-intent data feed. A team might use Common Room to ingest Bombora or other signals and activate them through supported workflows; that is a different architecture. Any separate export product or enterprise arrangement should be verified in a contract, not assumed from the inbound API.
TrustRadius is also a legitimate source of B2B software research signals and may deliver them through a purchased integration or data arrangement. For this API-specific shortlist, however, a standalone outbound buyer-intent endpoint, its fields and entitlement were not verified from the accessible public materials. Ask for an endpoint or delivery specification and sample payload if TrustRadius is commercially relevant. Once that evidence is supplied, evaluate it on the same schema, freshness and cost basis as G2. Do not label a native integration as an API feed without checking the direction of data flow.
Write the event contract before buying
A data engineer and RevOps owner should agree on a canonical record that can represent what each vendor actually delivers. Keep the original payload where storage rights permit, then normalize only the fields needed for decisions:
| Field | Example | Why it matters |
|---|---|---|
provider and provider_record_id |
g2, vendor ID or stable compound key |
Idempotent ingestion and traceability |
signal_type and object |
compare, product/category/topic |
Prevents a topic surge from masquerading as a product comparison |
observed_at and received_at |
source visit date and ingestion time | Separates old evidence from delayed delivery |
company_id, domain, country |
source identifier and resolved CRM account | Exposes uncertain parent/subsidiary mapping |
measure, window, baseline |
score, page-view total or stage | Keeps a relative surge distinct from a raw action |
source_reference |
page URL or topic ID | Lets an analyst explain why the account was flagged |
licence_scope and expires_at |
allowed use and retention date | Prevents silent reuse beyond contract terms |
This is a proposed internal contract, not a claim that all vendors provide all fields. When a field is absent, record it as absent; do not invent a timestamp or convert an aggregate into a single event. G2's visit date and last-seen fields support one design. Bombora's topic/window output may require another. A 6sense score may be a modelled attribute at query time rather than a retrievable historical event. Keep source-specific detail beside the normalized record.
Deduplicate before creating actions. A provider can resend data after a failed response, and a daily aggregate can change as more activity arrives. Key ingestion by source ID if available, otherwise a documented compound key that includes account, signal type, object and observation window. Record payload version and processing state. If the API returns 429, authentication failure or an empty page, retry safely and alert the data owner rather than treating “zero rows” as “zero buying activity.”
Price the accepted signal, not the record
None of these three options offers a reliable public one-line API price for the full requested workflow. Bombora and G2 are commercial data contracts whose included topics, products, signal types, delivery and history must be quoted. 6sense's API usage can be credit-based and package-gated. A third-party list price for a different bundle would create false precision. Request the same procurement schedule from each: licence or minimum term, which products/topics/accounts are covered, annual included calls or records, overage rate, historical backfill, API access, support and permitted downstream use.
For illustration, suppose a 50,000-account territory receives 6,000 vendor records in a month. After matching, 3,600 attach confidently to CRM accounts. Of those, 600 meet the team's ICP and recency rules, and sellers accept 120 as genuinely useful research tasks. A hypothetical $6,000 monthly-equivalent vendor contract would cost $50 per accepted task, not $1 per raw record. The number is a calculation template, not any vendor's price. If sales accepts only 40 tasks, the same contract costs $150 per accepted task. That sensitivity should inform a trial more than a vendor's total signal count.
Also price the machinery: one engineer's integration work, account-identity mapping, monitoring, deduplication, storage, privacy review and RevOps time. A native connector may cost more in licence fees but less in maintenance; an API may be worthwhile when the same evidence feeds several systems and needs custom policy. Compare the annual total at expected volume and at a high-volume month, including overage and failure handling.
A four-week integration pilot
In week one, choose one product or topic family and 500 known target accounts plus 100 deliberate non-fit accounts. Set expected account IDs, territories and sample seller actions before seeing the feed. Ask each vendor for the actual subscribed interface, test token and payload under the contract. Confirm history and permissible storage.
In week two, ingest a realistic batch or stream into a staging table. Log request IDs, response status, page or cursor, source record ID and received time without exposing API secrets. Reconcile counts against the vendor dashboard where one exists. Replay the same data twice and prove it creates one account signal, not two CRM tasks. Pause credentials or simulate a rate limit and confirm recovery.
In week three, have analysts review at least 100 matched signals. Is the account right? Is the source event or model output fresh enough? Does the rep understand what the company did, as opposed to a vague “high intent” label? Record false positives and account-hierarchy disagreements. Run the feed through a rule that combines intent with fit and existing ownership, and suppresses duplicate tasks for active opportunities.
In week four, expose a limited queue to sellers. Track accepted tasks, rejected tasks with reasons, qualified conversations and the manual time required to explain a signal. Compare those outcomes to total contract and operating cost. This does not establish a universal vendor winner; it tells you which source yields usable evidence for the exact workflow you plan to fund.
Which API fits your workflow?
Choose Bombora when changing topic research across accounts is the signal you need and the topic definition and relative measure are clear enough to act on. Choose G2 when software buyers research your product or category on its marketplace network and its documented activity fields satisfy the decision you want to automate. Choose 6sense when you already depend on its account graph or predictive scoring and can justify the required package and API credits.
If all you need is account prioritization in a CRM, compare a supported native integration before building a pipeline. If you need cross-source history, your own matching and a repeatable audit trail, an API is justified. Our B2B intent data providers guide covers the broader source choice, while 6sense vs Demandbase addresses the platform decision around one of these options.
Use the ABM Playbook to decide which account signals should change sales priority before automating API ingestion.
FAQ
Does a subscription to intent data automatically include an API?
No. Plans, topics, products, endpoints and permitted delivery can be separate. Ask for a sample response and written entitlement to the exact interface before signing.
Are Bombora and G2 signals interchangeable?
No. Bombora's Company Surge concerns elevated company-level research around topics; G2's Buyer Intent concerns activity such as product, category, pricing and comparison views on its research network. They differ in source, grain and meaning.
Why isn't Common Room one of the three API feeds?
Its current public API documentation explicitly says the API gets data into Common Room but not out. It can be useful as a signal destination or workflow platform, yet that documented API does not provide the outbound intent feed this article is evaluating.
Can G2 tell us which employee researched our product?
The published Buyer Intent data dictionary describes buyer organizations, visit/page types, region and timestamps, not a named visitor identity. Use the account signal for research and do not attribute the activity to a specific employee without another reliable source.
How does 6sense charge for company identification API use?
Its documentation says one matched company response consumes one API credit, and repeated identification of the same IP can consume credits again during the contract year. Other endpoints use different credit pools or subscription gates. Obtain your own allocation and overage terms.
What is the minimum viable activation rule?
Resolve the source company to a CRM account, require an allowed and recent signal type, check ICP fit and current owner, then create one explainable research task if no equivalent open task exists. Keep the provider, source object and timestamps available for review.
