Skip to main content

ChurnKey Data Source

The ChurnKey connector enables you to ingest cancel session records, aggregated churn metrics, and full customer data profiles from the ChurnKey Data API. This connector is particularly useful for centralizing retention analytics, building churn dashboards, and fulfilling GDPR data subject access requests. Follow the instructions below to create a new data flow that ingests data from a ChurnKey source in Nexla.
churnkey_api.png

ChurnKey

Create a New Data Flow​

  1. To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Then, select the desired flow type from the list, and click the Create button.

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

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

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

Configure Using a Template​

Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common ChurnKey endpoints. Each template is designed specifically for the corresponding ChurnKey endpoint, making data source setup easy and efficient.

Endpoint Settings​

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

    This endpoint returns a list of all cancel-flow sessions recorded in your ChurnKey account. Use it to ingest session-level retention data — such as save attempts, accepted offers, and cancellation outcomes — for analysis, reporting, or warehousing.

    • This endpoint retrieves session records from https://api.churnkey.co/v1/data/sessions using a GET request. No additional configuration is required beyond selecting this endpoint template.
    • Each element in the returned array is treated as an individual record, so the data is automatically organized into one record per session.

    The ChurnKey sessions endpoint returns up to 10,000 sessions per request. For accounts with high session volumes, consider scheduling regular ingestion runs to capture new sessions incrementally.

    Get Session Aggregation

    This endpoint returns aggregated session data and summary statistics for your ChurnKey account. Use it when you need rolled-up churn metrics rather than individual session records — for example, to populate executive dashboards or track retention trends over time.

    • This endpoint retrieves aggregated statistics from https://api.churnkey.co/v1/data/session-aggregation using a GET request. No additional configuration is required beyond selecting this endpoint template.
    • The endpoint returns a single aggregated object, so this source produces a single record representing the current account-level summary.

    Because this endpoint returns a point-in-time snapshot of aggregated metrics, schedule recurring ingestion runs if you want to track how these statistics change over time.

    Get DSR Data Access

    This endpoint fulfills a GDPR Data Subject Request (DSR) by returning all stored ChurnKey data for a single customer, identified by email address. The response includes the customer's events, sessions, campaigns, invoices, failed payments, subscriptions, charges, and emails. Use this endpoint to satisfy data subject access requests or to export a complete profile for a specific customer.

    • This endpoint issues a POST request to https://api.churnkey.co/v1/data/dsr/access. To configure it, provide the following parameter:

      • Customer Email — Enter the email address of the customer whose data subject access request data should be returned. This value is required and is sent in the request body to identify the customer.
    • The endpoint returns a single consolidated object containing all stored records for the specified customer.

    This endpoint is intended for fulfilling individual data subject access requests under GDPR. For additional details on ChurnKey's data subject request handling, refer to the ChurnKey Data API documentation.

Endpoint Testing​

Once the selected endpoint template has been configured, Nexla can retrieve a sample of the data that will be fetched according to the current settings. This allows users to verify that the source is configured correctly before saving.

  • To test the current endpoint configuration, click the Test button to the right of the endpoint selection menu. Sample data will be fetched & displayed in the Endpoint Test Result panel on the right.

  • If the sample data is not as expected, review the selected endpoint and associated settings, and make any necessary adjustments. Then, click the Test button again, and check the sample data to ensure that the correct information is displayed.

Configure Manually​

ChurnKey data sources can be manually configured to ingest data from any valid ChurnKey API endpoint. Manual configuration provides maximum flexibility for accessing endpoints not covered by pre-built templates or when you need custom API configurations.

With manual configuration, you can also create more complex ChurnKey sources, such as sources that use chained API calls to fetch data from multiple endpoints or sources that require custom request parameters.

API Method​

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

  2. Select the API method that will be used for calls to the ChurnKey API from the Method pulldown menu. The most common methods are:

    • GET: For retrieving data from the API, such as sessions or aggregated metrics
    • POST: For sending data to the API or triggering actions, such as the DSR data access request

API Endpoint URL​

  1. Enter the URL of the ChurnKey API endpoint from which this source will fetch data in the Set API URL field. This should be the complete URL including the protocol (https://) and any required path. ChurnKey Data API endpoints are based at https://api.churnkey.co/v1/data/.

Ensure the API endpoint URL is correct and accessible with your current credentials. You can test the endpoint using the Test button after configuring the URL.

Path to Data​

Optional

If only a subset of the data returned by the API endpoint is needed, you can designate the part(s) of the response that should be included in the Nexset(s) produced from this source by specifying the path to the relevant data within the response. This is particularly useful when API responses contain metadata, pagination information, or other data that you don't need for your analysis.

For example, the ChurnKey sessions endpoint returns a top-level array of session objects. By entering the path to the relevant data, you can configure Nexla to treat each element of the returned array as a record.

Path to Data is essential when API responses have nested structures. Without specifying the correct path, Nexla might not be able to properly parse and organize your data into usable records.

  • To specify which data should be treated as relevant in responses from this source, enter the path to the relevant data in the Set Path to Data in Response field.

    • For responses in JSON format, enter the JSON path that points to the object or array that should be treated as relevant data. JSON paths use dot notation (e.g., $[*] to treat each element of a top-level array as a record).
    Path to Data Example:

    For the ChurnKey sessions endpoint, which returns a top-level array of session objects, the path to the data would be entered as $[*] so that each session becomes a record.

Autogenerate Path Suggestions​

Nexla can also autogenerate data path suggestions based on the response from the API endpoint. These suggested paths can be used as-is or modified to exactly suit your needs.

  • To use this feature, click the Test button next to the Set API URL field to fetch a sample response from the API endpoint. Suggested data paths generated based on the content & format of the response will be displayed in the Suggestions box below the Set Path to Data in Response field.

  • Click on a suggestion to automatically populate the Set Path to Data in Response field with the corresponding path. The populated path can be modified directly within the field if further customization is needed.

    PathSuggestions.png

Metadata​

If metadata is included in the response but is located outside of the defined path to relevant data, you can configure Nexla to include this data as common metadata in each record. This is useful when you want to preserve important contextual information that applies to all records but isn't part of the main data array.

Metadata paths are particularly useful for preserving API response context like request IDs, timestamps, or summary statistics that apply to all records in the response.

  • To specify the location of metadata that should be included with each record, enter the path to the relevant metadata in the Path to Metadata in Response field.

    • For responses in JSON format, enter the JSON path to the object or array that contains the metadata.

Request Headers​

Optional

  • If Nexla should include any additional request headers in API calls to this source, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (e.g., header1:value1,header2:value2). Additional headers are often required for content type specifications or custom request requirements.

    You do not need to include any headers already present in the credentials. The ChurnKey x-ck-api-key and x-ck-app authentication headers are added automatically by Nexla based on your credential configuration.

Endpoint Testing​

After configuring all settings for the selected endpoint, Nexla can retrieve a sample of the data that will be fetched according to the current configuration. This allows users to verify that the source is configured correctly before saving.

  • To test the current endpoint configuration, click the Test button to the right of the endpoint selection menu. Sample data will be fetched & displayed in the Endpoint Test Result panel on the right.

  • If the sample data is not as expected, review the selected endpoint and associated settings, and make any necessary adjustments. Then, click the Test button again, and check the sample data to ensure that the correct information is displayed.

Save & Activate the Source​

  1. Once all of the relevant steps in the above sections have been completed, click the Create button in the upper right corner of the screen to save and create the new ChurnKey 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.