Skip to main content

Bitly 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 Bitly location.
bitly_api.png

Bitly

Create a Bitly Destination​

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

  2. Select the Bitly connector from the list of available destination connectors. Then, select the credential that will be used to connect to the Bitly account, and click Next; or, create a new Bitly credential for use in this flow.

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

    Bitly destinations can also be configured manually, allowing you to send data to Bitly 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 Bitly endpoints. Each template is designed specifically for the corresponding Bitly 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.

    Shorten a Link

    This endpoint shortens a long URL into a Bitlink. Use it as the fastest way to create Bitlinks at volume — for example, generating short links for every record in an upstream marketing list. It is functionally simpler than Create a Bitlink and is recommended when you only need a back-half and no advanced metadata.

    • Each record in the upstream Nexset must include a long_url attribute pointing to the destination URL. Optional attributes include domain (the BSD to use, for example bit.ly) and group_guid (the Bitly group that will own the link — defaults to the user's default group).
    • The full record is sent as the JSON body of the POST /v4/shorten call. Use the Nexla transform layer to shape upstream attributes into the field names expected by Bitly.

    When no group_guid is supplied, Bitly creates the link in the access token owner's default group. To target a specific group, first call the Retrieve Groups source endpoint and route the GUID through a transform.

    Create a Bitlink

    This endpoint creates a Bitlink with the full set of optional metadata — title, tags, deeplinks, expiration, group, campaign, and channel assignments. Use it when you need to provision Bitlinks that participate in campaign reporting or carry rich metadata.

    • Each record in the upstream Nexset must include a long_url attribute. Recommended optional fields include title, tags (array of strings), deeplinks, group_guid, campaign_guid, and channel_guids.
    • The full record is sent as the JSON body of the POST /v4/bitlinks call.

    Campaign and channel assignments require GUIDs from the Retrieve Campaigns and Retrieve Channels source endpoints. For complete payload reference, see the Bitly Create Bitlink documentation.

    Add Custom Bitlink

    This endpoint creates a custom Bitlink — a Bitlink with a chosen back-half on a branded short domain (BSD). Use it to programmatically provision branded links (for example, brand.ly/promo-2026).

    • Each record in the upstream Nexset must include custom_bitlink (the full custom URL, including the BSD host) and bitlink_id (the existing Bitlink that the custom URL should resolve to).
    • The full record is sent as the JSON body of the POST /v4/custom_bitlinks call.

    Custom Bitlinks require a Bitly plan that includes a Branded Short Domain. Use the List BSD Records source endpoint to discover available BSDs before populating custom_bitlink values.

    Update a Bitlink

    This endpoint updates the editable metadata of an existing Bitlink — title, tags, archive status, deeplinks, and expiration. Use it to keep Bitlink metadata synchronized with an upstream system of record.

    • Enter the Bitlink ID in the Bitlink field. The default value is {'{{id}}'}, which substitutes the id attribute from each upstream record — so the destination can be driven directly by a Retrieve Bitlinks by Group source.
    • The body of each PATCH call is the upstream record (as JSON). Include only the fields that should be changed; omitted fields are left untouched.

    This endpoint cannot change the Bitlink's long_url. To repoint a Bitlink to a different destination, create a new Bitlink or update the associated custom Bitlink with Update Custom Bitlink.

    Update Custom Bitlink

    This endpoint updates the Bitlink that an existing custom Bitlink resolves to. Use it to repoint a branded URL (for example, brand.ly/promo) to a new destination without changing the public-facing short link.

    • Enter the custom Bitlink in the Custom Bitlink field (for example, brand.ly/promo). This is required.
    • The body of each PATCH call must include a bitlink_id field with the target Bitlink to resolve to.

    Delete a Bitlink

    This endpoint archives (soft-deletes) a Bitlink. Archived Bitlinks stop tracking new clicks but remain in the account so historical metrics are preserved.

    • Enter the Bitlink ID in the Bitlink field. The default value is {'{{id}}'}, which substitutes the id attribute from each upstream record. This is required.
    • This call sends a DELETE with no body.

    Archiving is reversible — the same Bitlink can be unarchived later by sending a PATCH through the Update a Bitlink endpoint with archived: false.

    Create a QR Code

    This endpoint creates a new dynamic QR code, optionally with customization (color, frame, logo) and expiration. Use it to programmatically generate QR codes for print collateral, point-of-sale assets, or campaign deployments.

    • Each record in the upstream Nexset must include the fields required to create a QR — at minimum a long_url (or an existing bitlink_id to link to). Optional fields cover the QR's style and customization options.
    • The full record is sent as the JSON body of the POST /v4/qr-codes call.

    QR codes are dynamic — their destination can be updated later through the Bitly UI without reprinting the code. For style options, see the Bitly QR-code documentation.

    Create Campaign

    This endpoint creates a new Bitly campaign within a group. Use it to programmatically scaffold campaign records from an upstream marketing-planning system so links and reporting are organized from day one.

    • Each record in the upstream Nexset must include a name (campaign name) and group_guid (the group the campaign belongs to). Optional fields include description and an array of channel_guids to assign existing channels to the campaign.
    • The full record is sent as the JSON body of the POST /v4/campaigns call.

    Update Campaign

    This endpoint updates an existing campaign's name, description, group, or channel assignments. Use it to keep Bitly campaign metadata aligned with an upstream campaign-management system.

    • Enter the campaign GUID in the Campaign GUID field. The default value is {'{{guid}}'}, which substitutes the guid attribute from each upstream record. This is required.
    • The body of each PATCH call is the upstream record (as JSON). Include only the fields that should be changed; omitted fields are left untouched.

    Create Channel

    This endpoint creates a new channel — a logical grouping of Bitlinks within a campaign. Use it to programmatically scaffold channels alongside campaigns when bootstrapping a new marketing program in Bitly.

    • Each record in the upstream Nexset must include a name (channel name) and group_guid. Optional fields include description, guids (array of Bitlink IDs to assign to the channel), and campaign_guid to attach the channel to an existing campaign.
    • The full record is sent as the JSON body of the POST /v4/channels call.

    Update Channel

    This endpoint updates an existing channel's name, Bitlink assignments, or campaign association.

    • Enter the channel GUID in the Channel GUID field. The default value is {'{{guid}}'}, which substitutes the guid attribute from each upstream record. This is required.
    • The body of each PATCH call is the upstream record (as JSON). Include only the fields that should be changed.

    Update Group

    This endpoint updates a Bitly group's name or assigned Branded Short Domains (BSDs).

    • Enter the group GUID in the Group GUID field. The default value is {'{{guid}}'}, which substitutes the guid attribute from each upstream record. This is required.
    • The body of each PATCH call is the upstream record (as JSON). Include only the fields that should be changed.

    Update Group Preferences

    This endpoint updates the preferences (for example, default BSD) configured for a group. Use it to centrally enforce that all new Bitlinks created by a team use a specific branded short domain.

    • Enter the group GUID in the Group GUID field. The default value is {'{{guid}}'}, which substitutes the guid attribute from each upstream record. This is required.
    • The body of each PATCH call is the upstream record (as JSON). Include the preferences fields that should be changed.

    Update User

    This endpoint updates the authenticated user's profile — name, default group GUID, and other personal preferences.

    • No path parameters are required. The endpoint always updates the user associated with the access token.
    • The body of each PATCH call is the upstream record (as JSON). Include only the fields that should be changed.

    Because this endpoint operates on the authenticated user, route only the records that represent that user's profile into this destination — typically a single-row Nexset.

Configure Manually​

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

Using manual configuration, you can also configure Nexla to automatically send the response received from the Bitly API after each call to a new Nexla webhook data source — useful for capturing the IDs and metadata Bitly returns after creating Bitlinks, campaigns, channels, or QR codes.

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 Bitly API from the Method pulldown menu. Bitly v4 uses POST for creation, PATCH for partial updates, and DELETE for archiving Bitlinks.

Data Format​

  1. Select the format in which the Nexset data will be sent to the Bitly API from the Content Format pulldown menu. Bitly v4 expects application/json for all request bodies. Nexla automatically converts the Nexset data to the selected format for each API call.

API Endpoint URL​

  1. Enter the URL of the Bitly API endpoint to which you want to send the Nexset data in the URL field. Bitly v4 endpoints are all rooted at https://api-ssl.bitly.com/v4/. For update or delete operations, include the resource identifier (Bitlink, GUID, etc.) at the end of the URL — substitution placeholders like {'{{id}}'} or {'{{guid}}'} can be used to pull the identifier from each upstream record.

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). Additional headers are rarely needed with Bitly — Authorization is set automatically from the credential, and Content-Type: application/json is set by the destination's data format.

    You do not need to include the Authorization header — Nexla injects Authorization: Bearer {token} automatically from the credential.

Exclude Attributes from the Call​

Optional

  • If any record attributes in the Nexset should be omitted when sending data to this Bitly destination, select the attributes from the Exclude Attributes pulldown menu. This is useful when upstream records carry internal bookkeeping fields (for example, source-system IDs) that Bitly should not see.

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

Most Bitly write endpoints (/v4/shorten, /v4/bitlinks, /v4/campaigns, /v4/channels) accept a single resource per call and do not natively support batch payloads. Leave batching disabled unless you are sending to a custom endpoint that accepts an array of records.

Response Webhook​

Optional

Nexla can automatically send the response received from the Bitly 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, capturing the new Bitlink ID after a POST /v4/shorten call so it can be joined back into the upstream dataset.

  • 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 Bitly 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 Bitly 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 Bitly 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 send the data to Bitly, open the destination resource menu, and select Activate.

    The Nexset data will not be sent to Bitly until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.