Bombora is a B2B intent data and account intelligence provider that anonymously measures content consumption across a co-op of business websites and surfaces in-market signals as Company Surge® intent scores. The Bombora APIs expose account lists, digital audiences, intent data and signal definitions, B2B demographic reference data, and webhook destinations, enabling integrations to ingest intent signals and account intelligence into downstream systems and to programmatically manage audiences and signal definitions.
Power end-to-end data operations for your Bombora API with Nexla. Our bi-directional Bombora connector is purpose-built for Bombora, making it simple to ingest data, sync it across systems, and deliver it anywhere — all with no coding required. Nexla turns API-sourced data into ready-to-use, reusable data products and makes it easy to send data to Bombora or any other destination. With comprehensive monitoring, lineage tracking, and access controls, Nexla keeps your Bombora workflows fast, secure, and fully governed.
Features
Type: API
SourceDestination
Seamless API Integration: Connect to any endpoint as source or destination without coding, with automatic data product creation
Visual Composition & Chaining: Build complex integrations using visual templates, chain API calls, and compose workflows with data validation and filtering
API Proxy: Expose curated slices of your data securely with a secure and customizable API proxy that validates and transforms data on the fly
Request optimization with intelligent batching, retry, and caching to minimize API calls and costs
The Bombora APIs use the OAuth 2.0 client credentials grant for server-to-server authentication. A Nexla credential exchanges a Client ID and Client Secret at the Bombora token endpoint to obtain a short-lived bearer access token, which Nexla then sends in the Authorization header on every subsequent API call.
Client credentials are issued by Bombora to API customers through the Bombora Developer Portal. Before creating a credential in Nexla, complete the following steps.
API access to the Bombora platform is provisioned by Bombora as part of the customer onboarding process. The customer-facing portal at https://developer.bombora.com/ hosts the API reference for the Authentication API, Account List API, Digital Audience Builder (DAB) API, Intent API, Reference API, and Webhooks API.
Sign in to the Bombora Developer Portal using the account credentials provided by your Bombora account team. If your organization does not yet have access, contact your Bombora account representative to request API access.
Confirm with your Bombora account team which APIs your subscription is entitled to use (for example, Account List, Digital Audiences, Intent, or Webhooks). Endpoints outside of your entitlement return authorization errors even when the access token is valid.
OAuth 2.0 client credentials (a Client ID and a Client Secret) are issued by Bombora and are used to obtain bearer access tokens for the Bombora APIs.
Sign in to the Bombora Developer Portal, and locate the credentials issued for your organization. If credentials have not yet been issued, request them from your Bombora account representative.
Record the Client ID value. This identifier is sent on every token request to Bombora and is paired with the Client Secret to authenticate your application.
Record the Client Secret value, and store it in a secure secret manager. The Client Secret functions as a password for the API client — anyone in possession of the secret can request access tokens against your Bombora account.
The Bombora token endpoint exchanges client credentials for an OAuth 2.0 bearer access token. The default Bombora token URL is https://api.bombora.com/oauth/token, and this value is pre-populated in the Nexla credential overlay.
Keep the default token URL unless your Bombora account team has provided a different URL for your environment. In that case, replace the default value with the URL provided by Bombora.
Important
The Client Secret grants programmatic access to your Bombora account. Store it in a secure secret manager, never commit it to source control, and rotate it immediately if you suspect that it has been exposed.
After selecting the data source/destination type, click the Add Credential tile to open the Add New Credential overlay.
Enter a name for the credential in the Credential Name field and a short, meaningful description in the Credential Description field.
Bombora uses the OAuth 2.0 client credentials grant for server-to-server authentication. Nexla automatically requests a bearer access token from the Bombora token endpoint using the values configured below and applies the token to every API call.
Enter the Client ID issued by Bombora in the Client ID field. This identifier is sent on every token request to Bombora.
Enter the Client Secret issued by Bombora in the Client Secret field. This value is treated as a secret and is stored encrypted in Nexla.
Confirm the URL of the Bombora token endpoint in the Token URL field. The default value https://api.bombora.com/oauth/token applies to standard Bombora accounts; replace it only if your Bombora account team has provided a different URL for your environment.
Nexla validates the credential by calling a low-impact reference endpoint (https://api.bombora.com/reference/v1/demographic/b2b-personas) with the issued access token. A successful validation confirms that the Client ID, Client Secret, and Token URL values are correct and that the resulting token has access to the Bombora APIs.
Click the Save button at the bottom of the overlay. The newly added credential will now appear in a tile on the Authenticate screen during data source/destination creation and can be selected for use with a new data source or destination.
To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Select the Bombora connector tile, then select the credential that will be used to connect to the Bombora instance, and click Next; or, create a new Bombora credential for use in this flow.
Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common Bombora endpoints. Select the endpoint from which this source will fetch data from the Endpoint pulldown menu. Available endpoint templates are listed in the expandable boxes below. Click on an endpoint to see more information about it and how to configure your data source for this endpoint.
List Account Lists
This endpoint returns all account lists configured in your Bombora account. Account lists group the target accounts that intent measurement and audience activation are scoped to. Use this endpoint to sync your account-list catalog into a warehouse or to obtain account-list IDs for use with the account-list-scoped endpoints below.
No configuration is required for this endpoint beyond selecting it. The endpoint calls GET /account-list/v1/account-list and treats each element of the top-level accountLists array as a record.
This endpoint retrieves the full details of a single account list by ID. Use it to enrich an existing dataset of account-list IDs with the latest list metadata.
Enter the account list ID in the Account List ID field. This field is required. Account list IDs can be obtained from the List Account Lists endpoint or from upstream Nexla data flows.
Search Accounts
This endpoint searches for accounts within a specific account list and returns the matching accounts in a single response. Use it for ad-hoc lookups against an account list — for example, to confirm whether a specific company is included in a target list.
Enter the account list ID in the Account List ID field. This field is required and identifies the list to search within. Account list IDs can be obtained from the List Account Lists endpoint.
Enter the search criteria in the Search Query field. This field is optional — leave it blank to return all accounts in the list, or enter the value to filter by (for example, a domain or company name).
This endpoint uses POST /account-list/v1/account-list/<id>/accounts/search with the query value passed in the JSON request body. For very large lists, prefer the Get Search Results endpoint, which paginates through results using a page token.
Get Search Results
This endpoint retrieves the accounts within a specific account list using token-based pagination. Use it to sync the full membership of a large account list into a warehouse or downstream system.
Enter the account list ID in the Account List ID field. This field is required and identifies the list to retrieve accounts from.
Enter the maximum number of results per page in the Limit field. This field is optional and defaults to 100. Larger pages reduce the number of HTTP calls; smaller pages reduce per-call payload size.
Nexla automatically follows the pageToken values returned by Bombora until all results have been retrieved, so the Limit value controls page size — not the total number of records that will be ingested.
Get Digital Audience
This endpoint retrieves the full details of a single digital audience by data exchange, external ID, and partner ID. Digital audiences are activation segments that Bombora distributes to a partner data exchange such as a DSP or DMP. Use this endpoint to read back the configuration of an existing audience.
Enter the data exchange identifier in the Data Exchange field. This field is required and identifies the destination platform for the audience (for example, the partner exchange where the audience is delivered).
Enter the external identifier of the audience in the External ID field. This field is required and uniquely identifies the audience within the data exchange.
Enter the partner identifier in the Partner ID field. This field is required and identifies the partner account that the audience belongs to.
This endpoint searches the Bombora intent dataset using a JSON filter object and returns the matching records. Use it for targeted intent queries — for example, to retrieve Company Surge® scores for a specific topic cluster, account list, or time window.
Enter the filter criteria in the Search Filters field as a JSON object. This field is optional and defaults to {}, which returns the full dataset available to your credential. Refer to the Bombora Intent API documentation for the supported filter fields.
The filter object is sent in the JSON request body wrapped in a filters property — for example, {"filters": {"topic": "Data Integration"}}. Use this endpoint when the entire result set fits in a single response; for paginated retrieval, use List Intent Data.
List Intent Data
This endpoint returns Bombora intent data records using token-based pagination. Use it to ingest the full intent dataset that your credential is entitled to — for example, into a warehouse for downstream scoring or attribution modeling.
Enter the maximum number of records per page in the Limit field. This field is optional and defaults to 100. Nexla automatically follows the pageToken values returned by Bombora until all results have been retrieved.
Intent datasets can be very large. For periodic full refreshes, schedule the source during low-traffic periods; for incremental ingestion, prefer Search Intent Data with a date filter that matches your refresh cadence.
List Signal Definitions
This endpoint returns all signal definitions configured in your Bombora account. A signal definition specifies the topics and thresholds that drive intent measurement for a given use case. Use this endpoint to sync your signal-definition catalog into a warehouse or to obtain signal-definition IDs for use with the signal-definition-scoped endpoints below.
No configuration is required for this endpoint beyond selecting it. The endpoint calls GET /intent/v1/signal-definitions and treats each element of the top-level data array as a record.
Get Signal Definition
This endpoint retrieves the full details of a single signal definition by ID. Use it to enrich an existing dataset of signal-definition IDs with the latest configuration — for example, the topic list and threshold settings associated with the signal.
Enter the signal definition ID in the Signal Definition ID field. This field is required. Signal definition IDs can be obtained from the List Signal Definitions endpoint or from upstream Nexla data flows.
List B2B Personas
This endpoint returns the B2B personas available for demographic segmentation in Bombora. Personas describe the buyer roles that Bombora classifies content consumption against. Use this endpoint to sync the persona reference dataset into a warehouse, or to look up valid persona identifiers when configuring downstream segmentation.
No configuration is required for this endpoint beyond selecting it. The endpoint calls GET /reference/v1/demographic/b2b-personas and treats each element of the top-level personas array as a record.
This endpoint is also used by Nexla to validate Bombora credentials during the credential save step.
List Functional Areas
This endpoint returns the functional areas available for demographic classification in Bombora. Functional areas describe the job-family taxonomy (for example, Engineering, Marketing) that Bombora classifies content consumption against. Use this endpoint to sync the functional-area reference dataset into a warehouse.
No configuration is required for this endpoint beyond selecting it. The endpoint calls GET /reference/v1/demographic/functional-area and treats each element of the top-level functionalAreas array as a record.
List Webhook Destinations
This endpoint returns all webhook destinations configured in your Bombora account. Webhook destinations are HTTP endpoints that Bombora calls when subscribed events occur. Use this endpoint to inventory the webhook destinations in your account or to obtain destination IDs for use with the Get Webhook Destination endpoint.
No configuration is required for this endpoint beyond selecting it. The endpoint calls GET /webhooks/v1/destinations and treats each element of the top-level destinations array as a record.
Get Webhook Destination
This endpoint retrieves the full configuration of a single webhook destination by ID. Use it to enrich an existing dataset of webhook-destination IDs with the latest URL, event subscriptions, and authentication settings.
Enter the webhook destination ID in the Destination ID field. This field is required. Destination IDs can be obtained from the List Webhook Destinations endpoint or from upstream Nexla data flows.
Once the selected endpoint template has been configured, click the Test button to the right of the endpoint selection menu to retrieve a sample of the data that will be fetched. Sample data will be displayed in the Endpoint Test Result panel on the right, allowing you to verify that the source is configured correctly before saving.
Bombora data sources can also be manually configured to ingest data from any valid Bombora API endpoint, including endpoints not covered by the pre-built templates, chained API calls, or custom request bodies and query parameters. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, endpoint URL, date/time and lookup macros, path to data, metadata, and request headers.
Most Bombora read endpoints use the GET method; intent and account-list search endpoints use POST with filter criteria passed in a JSON request body. Bombora API endpoints follow the format https://api.bombora.com/<api>/v1/<resource> — for example, https://api.bombora.com/intent/v1/data or https://api.bombora.com/account-list/v1/account-list. Bombora list endpoints return a top-level array named for the resource, so the path to data for the intent endpoint /intent/v1/data would be entered as $.data[*]. You do not need to add an Authorization header — the Bombora bearer-token header is handled automatically by Nexla based on your credential configuration.
Once all of the relevant settings have been configured, click the Create button in the upper right corner of the screen to save and create the new Bombora data source. Nexla will now begin ingesting data from the configured endpoint and will organize any data that it finds into one or more Nexsets.
Click the + icon on the Nexset that will be sent to the Bombora destination, and select the Send to Destination option from the menu. Select the Bombora connector from the list of available destination connectors, then select the credential that will be used to connect to the Bombora account, and click Next; or, create a new Bombora credential for use in this flow.
Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Bombora endpoints. Select the endpoint to which data will be sent from the Endpoint pulldown menu. Then, click on the template in the list below to expand it, and follow the instructions to configure additional endpoint settings.
Create Account List
This endpoint creates a new account list in Bombora. Account lists group the target accounts that intent measurement and audience activation are scoped to. Use this endpoint to provision new account lists from upstream CRM or ABM systems.
No endpoint-specific parameters are required. Each upstream record is sent as the JSON body of the POST call to /account-list/v1/account-list. Map upstream attributes to the account-list field names expected by Bombora, such as the list name and any optional metadata.
This endpoint updates an existing account list. Use it to keep account-list metadata in sync with a downstream system of record — for example, when the name or description of an ABM target list changes.
Enter the account list ID in the Account List ID field. This field is required and identifies the list to update. To drive the destination from an upstream source, map the upstream record's account-list identifier into this field.
The body of each PUT call is the upstream record (as JSON). Include only the fields that should be changed; omitted fields are left untouched.
Delete Account List
This endpoint deletes an account list by ID. The deletion is permanent, so validate upstream data carefully before activating this destination.
Enter the account list ID in the Account List ID field. This field is required and identifies the list to delete.
Because deletion is irreversible, consider routing through a Nexla transform that filters to only the account lists that should genuinely be deleted before activating this destination.
Add or Update Accounts
This endpoint adds new accounts to an account list or updates existing ones. Use it to keep an account list synchronized with an upstream system — for example, refreshing a target list with the latest accounts from a CRM or ABM platform.
Enter the account list ID in the Account List ID field. This field is required and identifies the list that the accounts will be written to.
Each upstream record is sent as the JSON body of the POST call. Map upstream attributes to the account fields expected by Bombora (for example, company domain).
Delete All Accounts
This endpoint removes every account from a specified account list. Use it to fully reset the membership of an account list before reloading it with a fresh upstream snapshot.
Enter the account list ID in the Account List ID field. This field is required and identifies the list to clear.
This operation removes all accounts from the list in a single call. Pair it with the Add or Update Accounts endpoint to implement a clean-and-reload pattern.
Create Digital Audience
This endpoint creates a new digital audience on the specified data exchange. Digital audiences are activation segments that Bombora distributes to a partner data exchange such as a DSP or DMP. Use this endpoint to provision new audiences from upstream segmentation logic.
Enter the data exchange identifier in the Data Exchange field. This field is required and identifies the destination platform where the audience will be created.
Each upstream record is sent as the JSON body of the POST call. Map upstream attributes to the audience fields expected by Bombora (for example, audience name, targeting criteria, and partner metadata).
This endpoint estimates the size of a digital audience based on the targeting criteria in the request body. Use it to validate that a candidate audience definition will produce a usable reach before creating the audience.
Enter the data exchange identifier in the Data Exchange field. This field is required and identifies the data exchange that the estimate will be scoped to.
Each upstream record is sent as the JSON body of the POST call to /digital-audiences/v1/<dataexchange>/estimate. Map upstream attributes to the audience criteria expected by Bombora.
Update Digital Audience
This endpoint updates the configuration of an existing digital audience. Use it to refresh targeting criteria as upstream segmentation logic evolves, without recreating the audience or changing its identity on the partner exchange.
Enter the data exchange identifier in the Data Exchange field. This field is required and identifies the exchange that the audience belongs to.
Enter the external identifier of the audience in the External ID field. This field is required and uniquely identifies the audience within the exchange.
Enter the partner identifier in the Partner ID field. This field is required and identifies the partner account that the audience belongs to.
The body of each PUT call is the upstream record (as JSON). Include only the fields that should be changed; omitted fields are left untouched.
Create Signal Definition
This endpoint creates a new signal definition for intent tracking. A signal definition specifies the topics and thresholds that drive intent measurement for a given use case. Use this endpoint to provision new signals from upstream go-to-market planning.
No endpoint-specific parameters are required. Each upstream record is sent as the JSON body of the POST call to /intent/v1/signal-definition. Map upstream attributes to the signal-definition fields expected by Bombora — typically a name and a list of topics or topic clusters.
This endpoint updates the core configuration of an existing signal definition. Use it to refresh the topic list or other definition-level settings without recreating the signal.
Enter the signal definition ID in the Signal Definition ID field. This field is required and identifies the signal to update.
The body of each PUT call is the upstream record (as JSON). Include only the fields that should be changed; omitted fields are left untouched.
Update Signal Definition Metadata
This endpoint updates only the metadata portion of a signal definition — for example, descriptive fields used for governance and reporting — without changing the underlying topic logic.
Enter the signal definition ID in the Signal Definition ID field. This field is required and identifies the signal whose metadata to update.
The body of each PUT call is the upstream record (as JSON). Map upstream attributes to the metadata fields expected by Bombora.
Update Product Definition
This endpoint updates the product definition associated with a signal definition. The product definition links a signal to a specific product or solution that the signal is intended to measure intent for.
Enter the signal definition ID in the Signal Definition ID field. This field is required and identifies the signal whose product definition to update.
The body of each PUT call is the upstream record (as JSON). Map upstream attributes to the product-definition fields expected by Bombora.
Create Webhook Destination
This endpoint creates a new webhook destination that Bombora will call when subscribed events occur. Use it to register downstream systems (for example, an integration platform or a Nexla webhook source) as receivers for Bombora event notifications.
No endpoint-specific parameters are required. Each upstream record is sent as the JSON body of the POST call to /webhooks/v1/destination. Map upstream attributes to the webhook fields expected by Bombora, such as the destination URL and event subscriptions.
Update Webhook Destination
This endpoint updates the configuration of an existing webhook destination. Use it to change the destination URL, event subscriptions, or other settings as downstream integrations evolve.
Enter the webhook destination ID in the Destination ID field. This field is required and identifies the webhook to update.
The body of each PUT call is the upstream record (as JSON). Include only the fields that should be changed; omitted fields are left untouched.
Delete Webhook Destination
This endpoint deletes a webhook destination by ID. The deletion is permanent, so validate upstream data carefully before activating this destination.
Enter the webhook destination ID in the Destination ID field. This field is required and identifies the webhook to delete.
Update Destination Auth
This endpoint updates the authentication settings that Bombora uses when calling a webhook destination. Use it to rotate the secrets or tokens that secure the receiver — for example, after a downstream system rotates its inbound credentials.
Enter the webhook destination ID in the Destination ID field. This field is required and identifies the webhook whose authentication to update.
The body of each PUT call is the upstream record (as JSON). Map upstream attributes to the authentication fields expected by Bombora.
Authentication credentials transmitted in this payload should be treated as secrets. Route them through Nexla transforms that source the values from a secure secret store rather than embedding them in upstream data.
Update Webhook Event
This endpoint updates the configuration of a specific event type subscribed to on a webhook destination. Use it to fine-tune event-level behavior — for example, toggling individual event types on or off for an existing destination.
Enter the webhook destination ID in the Destination ID field. This field is required and identifies the webhook whose event configuration to update.
Enter the event type in the Event Type field. This field is required and identifies the specific event whose configuration will be updated.
The body of each PUT call is the upstream record (as JSON). Map upstream attributes to the event-configuration fields expected by Bombora.
Bombora destinations can also be manually configured to send data to any valid Bombora API endpoint. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, data format, endpoint URL, request headers, attribute exclusions, record batching, and response webhooks.
The Bombora APIs expect application/json, so use JSON as the content format. Bombora API endpoints follow the format https://api.bombora.com/<api>/v1/<resource> — for example, https://api.bombora.com/account-list/v1/account-list or https://api.bombora.com/digital-audiences/v1/<dataexchange>; for update operations, include the ID of the object to be updated at the end of the URL. Use POST to create records, PUT to update existing records, and DELETE to remove records. Record batching is best suited to Bombora endpoints that explicitly accept an array of items in the request body — such as the Add or Update Accounts endpoint. You do not need to add an Authorization header — the Bombora bearer-token header is handled automatically by Nexla based on your credential configuration.
Once all endpoint settings have been configured, click the Done button in the upper right corner of the screen to save and create the destination. To begin sending data to Bombora, open the destination resource menu, and select Activate.
The Nexset data will not be sent to Bombora until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.
