Skip to main content

Bombora Destination

Nexla's bi-directional connectors allow data to flow both to and from any location, making it simple to create a FlexFlow data flow that sends data to a Bombora location.
bombora_api.png

Bombora

Create a Bombora Destination​

  1. Click the + icon on the Nexset that will be sent to the Bombora destination, and select the Send to Destination option from the menu.

  2. 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.

  3. In Nexla, Bombora destinations can be created using pre-built endpoint templates, which expedite destination setup for common Bombora endpoints. Each template is designed specifically for the corresponding Bombora endpoint, making destination configuration easy and efficient.
    • To configure this destination using a template, follow the instructions in Configure Using a Template.

    Bombora destinations can also be configured manually, allowing you to send data to Bombora endpoints not included in the pre-built templates or apply further customizations to exactly suit your needs.
    • To configure this destination manually, follow the instructions in Configure Manually.

Configure Using a Template​

Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Bombora endpoints. Each template is designed specifically for the corresponding Bombora endpoint, making destination setup easy and efficient.

  • To configure this destination using a template, 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.

    For the full Account List API contract, see the Bombora Account List API documentation.

    Update Account List

    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).

    For the full Digital Audience Builder API contract, see the Bombora Digital Audience API documentation.

    Estimate Audience Size

    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.

    For the full Intent API contract, see the Bombora Intent API documentation.

    Update Signal Definition

    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.

Configure Manually​

Bombora destinations can be manually configured to send data to any valid Bombora API endpoint.

Using manual configuration, you can also configure Nexla to automatically send the response received from the Bombora API after each call to a new Nexla webhook data source.

API Method​

  1. To manually configure this destination, select the Advanced tab at the top of the configuration screen.

  2. Select the API method that will be used for calls to the Bombora API from the Method pulldown menu. Use POST to create records, PUT to update existing records, and DELETE to remove records.

Data Format​

  1. Select the format in which the Nexset data will be sent to the Bombora API from the Content Format pulldown menu. The Bombora APIs expect application/json, so JSON is the appropriate format for most operations. Nexla will automatically convert the data to the selected format for each API call.

API Endpoint URL​

  1. Enter the URL of the Bombora API endpoint to which you want to send the Nexset data in the URL field. 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.

Request Headers​

Optional

  • If Nexla should include any additional request headers in API calls to this destination, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (e.g., header1:value1,header2:value2).

    You do not need to include any headers already present in the credentials. The Bombora Authorization bearer-token header is handled automatically by Nexla based on your credential configuration.

Exclude Attributes from the Call​

Optional

  • If any record attributes in the Nexset should be omitted when sending data to this Bombora destination, select the attributes from the Exclude Attributes pulldown menu.

  • Any number of attributes can be selected for exclusion, and all excluded attributes will be shown in the field. To remove an attribute from the list, click the X icon next to the attribute name.

Record Batching​

Optional

  1. If records should be sent to this destination in batched API calls, check the box next to Would you like to batch your records together? to enable record batching.

  2. Enter the maximum number of records that should be batched together in a single API call in the Batch Size field. By default, this value is set to 100.

  3. Select the algorithm that will be used to group records into batches from the Grouping Algorithm pulldown menu. The sample request shown in the panel on the right will be updated to reflect the current batching settings. Some algorithms require additional settings—click on an algorithm listed below to view instructions for configuring these settings.

    Property Inside JSON Object

    1. Enter the name of the JSON property that should contain the batched records in the Property Name field.
    2. If any additional properties should be included in the request, enter the properties in the Other Props field in JSON format.

    Code

    1. Enter the code that will be used to create the batched request in the code editor below the Grouping Algorithm field.

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. Confirm that the target endpoint supports batched payloads before enabling this option.

Response Webhook​

Optional

Nexla can automatically send the response received from the Bombora API after each call to a new Nexla webhook data source. This option allows you to keep track of the status of each API call and any additional information returned after each call — for example, the IDs that Bombora assigns to newly created account lists, audiences, or signal definitions.

  • To enable this option, check the box next to Would you like to process the API response as a Nexla Webhook source?.

Sample Request Payload​

Sample request payloads containing a portion of the Nexset data that will be sent to the Bombora API endpoint based on the current settings are shown in the Sample Payload panel on the right. These samples can be referenced to ensure that the destination and request settings are correctly configured.

  • Click on a sample request payload to expand it and view the complete payload content.
  • Sample payloads are automatically updated with each setting change, making it easy to verify that changes achieve the desired effect.

Endpoint Testing (Manual Configuration)​

After all endpoint settings have been configured, Nexla can send a test payload to the Bombora API to ensure that the destination is configured correctly.

  1. To send a test payload, select the Test button at the top of the Sample Payload panel, and click on a listed sample payload to expand it.

  2. If any modifications to the sample payload are needed, make the necessary changes directly within the sample window.

  3. Click the Send Test Data button at the top of a sample payload to send the test payload to the Bombora API using the current settings.

Save & Activate the Destination​

  • 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.