Skip to main content

Ding Connect

DingConnect is a global mobile top-up and airtime transfer platform operated by Ding. It lets businesses programmatically deliver prepaid airtime, data top-ups, e-gift cards, and utility bill payments across 150+ countries and 700+ operator networks. Its REST API covers the full transfer lifecycle: catalog browsing, account validation, transfer execution, reconciliation, and balance management.

Ding Connect icon

Power end-to-end data operations for your Ding Connect API with Nexla. Our bi-directional Ding Connect connector is purpose-built for Ding Connect, 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 Ding Connect or any other destination. With comprehensive monitoring, lineage tracking, and access controls, Nexla keeps your Ding Connect 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

Prerequisites​

To connect Nexla to Ding Connect, you need an active DingConnect distributor account and API credentials. DingConnect supports two authentication methods: OAuth 2.0 (Client Credentials) — the recommended method for all new integrations — and a legacy API Key for backward compatibility with existing integrations.

Register for a DingConnect Account​

If you do not already have a DingConnect account, visit dingconnect.com and apply to become a partner. DingConnect serves businesses such as OTT platforms, financial institutions, retailers, and POS providers. Once your application is approved, you will receive access to the DingConnect portal (also known as DingPartner+).

OAuth 2.0 using the client credentials flow is the recommended authentication method for all new DingConnect integrations. This flow is designed for server-to-server API requests and does not require user interaction.

  1. Sign in to the DingConnect portal.

  2. Navigate to Account Settings, then click the Developer tab. This tab lists all API credentials — both OAuth and API Key — in a table.

  3. In the OAuth Credentials section, click the button to generate new OAuth credentials. A Client ID and Client Secret will be created and displayed.

    Important

    Copy your Client Secret immediately and store it securely. It will not be shown again after you leave this page.

  4. Optionally, configure IP whitelisting for the credential by clicking Edit under the IP Whitelisting column. Enter a comma-separated list of IP addresses, subnets, or fully qualified domain names that are permitted to use this credential. This restricts API access to your known Nexla infrastructure addresses.

  5. The Access Token URL for DingConnect is https://idp.ding.com/connect/token. This is the endpoint where Nexla will exchange your Client ID and Client Secret for a short-lived Bearer token. You do not need to change this value unless DingConnect instructs otherwise.

DingConnect also provides a test environment. If you created your OAuth credentials under a Test Agent in the DingConnect portal, those credentials will operate in test mode and will not execute live transfers or charge your account.

Obtain a Legacy API Key (Optional)​

If you are maintaining a legacy integration that already uses an API key, you can retrieve or generate a key from the same Developer tab in Account Settings.

  1. Sign in to the DingConnect portal.

  2. Navigate to Account Settings > Developer tab.

  3. In the API Key Credentials section, generate a new API key if one does not already exist. The key is a static string that is sent as the api_key HTTP header on every API request.

  4. Optionally, configure IP whitelisting for the key by clicking Edit under the IP Whitelisting column.

DingConnect recommends using OAuth 2.0 for all new integrations. The API key method is maintained for backward compatibility only. Each Test Agent in DingConnect can have a maximum of two API keys and two OAuth2 credentials.

Authenticate​

Credentials required​

OAuth 2.0 client-credentials flow (Ding's recommended auth for new integrations). Bearer token issued by https://idp.ding.com/connect/token from client_id/client_secret, sent as Authorization: Bearer.

FieldRequiredSecretDescription
Client IDYesNoOAuth 2.0 client identifier issued by Ding Connect for your integration.
Client SecretYesYesOAuth 2.0 client secret paired with the client ID. Used to authenticate token requests.
Access Token URLYesNoOAuth 2.0 token endpoint. Defaults to the Ding Connect identity provider.

Create a credential in Nexla​

  1. After selecting the data source/destination type, click the Add Credential tile to open the Add New Credential overlay.

  2. Enter a name for the credential in the Credential Name field and a short, meaningful description in the Credential Description field.

  3. DingConnect supports two authentication methods. Select the tab below that corresponds to the method you are configuring.

Ding Connect Authentication Methods

OAuth 2.0 using the client credentials flow is Ding Connect's recommended authentication method for all new integrations. Nexla will automatically obtain and refresh a short-lived Bearer token from the Ding identity provider using your Client ID and Client Secret — no manual token management is required.

  1. Enter your OAuth 2.0 **Client ID** in the **Client ID** field. This is the client identifier issued when you generated OAuth credentials in the DingConnect portal under **Account Settings** > **Developer** tab.
  2. Enter your OAuth 2.0 **Client Secret** in the **Client Secret** field. This secret is paired with the Client ID and is used to authenticate token requests to the Ding identity provider. Treat this value as a password and do not share it.
  3. Verify that the **Access Token URL** field contains `https://idp.ding.com/connect/token`. This is the DingConnect OAuth token endpoint where Nexla will request Bearer tokens. This value defaults to the correct Ding identity provider URL and should only be changed if DingConnect explicitly instructs you to use a different token endpoint.
  1. 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.

Use as a data source​

To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Select the Ding Connect connector tile, then select the credential that will be used to connect to the Ding Connect instance, and click Next; or, create a new Ding Connect credential for use in this flow.

Endpoint templates​

Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common Ding Connect 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 Countries

Returns a list of all countries supported by the DingConnect platform. Use this endpoint to populate or refresh a reference table of available country codes and names, which can be used to filter or validate subsequent requests — such as looking up products or providers for a specific country.

  • No additional parameters are required for this endpoint. After selecting it from the Endpoint menu, Nexla will automatically retrieve all supported countries using paginated requests, fetching up to 100 records per page until the full list is returned.
  • The response includes country codes (ISO 3166 format) and country names. These country codes are referenced in other DingConnect endpoints such as List Products and List Providers.

This endpoint uses offset-based pagination. Nexla handles pagination automatically — you do not need to configure any additional paging parameters.

List Currencies

Returns a list of all currencies supported by the DingConnect platform. Use this endpoint to build or refresh a reference table of supported currency codes and their display names, which can then be used when interpreting product pricing data or validating send/receive value fields.

  • No additional parameters are required for this endpoint. Nexla will automatically retrieve the complete currency list using paginated requests.
  • The response includes ISO 4217 currency codes (e.g., USD, EUR, GBP) and their full names. Currency codes appear in product pricing records returned by the List Products endpoint.

This endpoint uses offset-based pagination. Nexla handles pagination automatically — no additional configuration is needed.

List Regions

Returns a list of all geographic regions covered by DingConnect services. Regions are sub-groupings within countries used by some providers to define the geographic scope of their products. Use this endpoint to populate a reference table of region codes that can be used to filter product or provider lookups.

  • No additional parameters are required for this endpoint. Nexla will automatically retrieve all regions using paginated requests, fetching up to 100 records per page.
  • Region codes returned by this endpoint can be used as filter parameters in the List Products and List Providers endpoints when you want to narrow results to a specific geographic area.

List Products

Returns a list of all available products offered through the DingConnect catalog. Products represent specific airtime, data, or digital top-up SKUs that can be sent via the Send Transfer destination endpoint. Use this endpoint to synchronize the product catalog into your data warehouse or analytics environment for pricing analysis, product selection, and integration with your customer-facing interfaces.

  • No additional parameters are required for this endpoint. Nexla will automatically retrieve the complete product catalog using paginated requests, fetching up to 100 products per page until the full catalog is returned.

  • Each product record includes the following key fields:

    • SkuCode: The unique product identifier required when executing a Send Transfer. Only SkuCode values returned by this endpoint should be used — do not attempt to guess or manufacture SkuCodes.
    • SendValue / ReceiveValue: The send and receive amounts for the product, expressed in the distributor's send currency and the recipient's local currency respectively.
    • ProviderCode: The code for the mobile network operator (MNO) that delivers the product.
    • CountryIso: The ISO 3166 country code where the product is available.

DingConnect recommends refreshing your product catalog regularly, as SKUs, pricing, and availability can change. Consider scheduling this data source to run daily or weekly to keep your catalog current.

List Providers

Returns a list of all mobile network operator (MNO) service providers available in the DingConnect network. Use this endpoint to populate a reference table of provider codes and names, which can be used to filter products by provider, look up provider status, or validate the provider for a given account number.

  • No additional parameters are required. Nexla will automatically retrieve all providers using paginated requests, fetching up to 100 records per page.
  • Each provider record includes a ProviderCode (used as an identifier in other API calls), the provider's display name, and the country or region where the provider operates.

List Error Code Descriptions

Returns a static list of all error codes and their human-readable descriptions for the DingConnect API. Use this endpoint to build an error code reference table that can be joined against transfer records or API response logs to make error messages understandable to operations and support teams.

  • No parameters are required. This endpoint returns the complete error code dictionary in a single, non-paginated response.
  • This endpoint is particularly useful for enriching transfer reconciliation data — by joining transfer records with the error code table, you can surface meaningful failure reasons without requiring API knowledge.

Unlike other DingConnect endpoints, List Error Code Descriptions is not paginated and returns the full list in one request. It is recommended to refresh this reference table periodically, as DingConnect may add new error codes when new features or providers are introduced.

List Promotions

Returns a list of all currently active promotions and special offers available through DingConnect. Use this endpoint to surface promotional offers in customer-facing applications, analyze promotional activity across regions, or trigger promotional campaigns in downstream systems.

  • No additional parameters are required. Nexla will automatically retrieve all current promotions using paginated requests, fetching up to 100 records per page.
  • Promotions are time-limited and tied to specific products or providers. Consider scheduling this data source to run frequently (e.g., hourly or daily) to ensure your system reflects current promotional availability.

List Product Descriptions

Returns detailed descriptive information for all available products in the DingConnect catalog. While the List Products endpoint returns pricing and SKU data, this endpoint provides marketing-oriented descriptions that can be used to populate product listings, customer-facing UIs, or catalog databases with human-readable content.

  • No additional parameters are required. Nexla will automatically retrieve all product descriptions using paginated requests, fetching up to 100 records per page.
  • Use this endpoint in conjunction with List Products — join on SkuCode to enrich the product catalog with descriptive text, benefit descriptions, or localized labels.

Get Balance

Returns the current credit balance of the authenticated DingConnect distributor account. Use this endpoint as a pre-flight check before executing batch transfers to verify that your account holds sufficient funds, or schedule it to run at regular intervals to monitor balance levels and trigger low-balance alerts in downstream systems.

  • No parameters are required. This endpoint returns a single non-paginated response containing the current balance amount and the currency in which the balance is held.
  • Consider routing the output of this source into a monitoring flow that alerts your team when the balance drops below a defined threshold — helping to prevent transfer failures caused by insufficient funds.

This endpoint returns the balance for the account associated with the credential used. If your organization has multiple DingConnect accounts (e.g., production and test), ensure you are using the correct credential when monitoring live account balances.

Lookup Account

Validates a mobile account number (typically a phone number including country code) and returns the matching provider, region, and country. Use this endpoint to pre-validate destination phone numbers before executing a Send Transfer, reducing failed transactions caused by invalid or unresolvable account numbers.

  • Enter the mobile phone number to validate in the Account Number field. The account number should include the international country dialing code (e.g., +1 for the United States, +44 for the United Kingdom) without spaces or special characters.

  • The response returns the matched provider code, region code, and country code for the account number. These values can be used to confirm the correct operator before selecting a product SKU and sending a transfer.
  • A successful lookup does not guarantee that a transfer will succeed — it only confirms that DingConnect can resolve the account number to a provider. Always verify that a suitable product SKU is available for the identified provider before executing a transfer.

The Account Number field is required. Include the full international number with country code. For example, a UK mobile number would be entered as +447911123456.

List Provider Status

Returns the current operational status of DingConnect providers (e.g., up, down, or degraded). Use this endpoint to monitor provider health before routing transfers, build provider health dashboards, or implement automated routing logic that avoids degraded providers.

  • Optionally, enter a comma-separated list of provider codes in the Provider Codes field to filter the response to specific providers. Leave this field blank to retrieve the status of all providers in the DingConnect network.

  • Provider codes can be obtained from the List Providers endpoint. If you are monitoring a specific set of providers relevant to your business (e.g., providers in a specific country or region), filtering by provider code reduces the response size and makes downstream processing more efficient.
  • Consider scheduling this data source to run frequently (e.g., every 15 to 30 minutes) when building a real-time provider health monitoring flow, so that your system can react quickly to provider outages.

The Provider Codes parameter is optional. When left blank, the status of all providers is returned.

List Transfer Records

Returns historical and in-flight transfer records from your DingConnect distributor account. Use this endpoint to reconcile completed transactions, audit transfer activity, monitor batch-mode transfers that have not yet been processed, or feed transfer data into a reporting or analytics pipeline.

  • No additional Nexla-side parameters are required for this endpoint. Nexla will automatically retrieve transfer records using paginated POST requests, fetching up to 100 records per page until all records are returned.

  • Transfer records include the following key fields:

    • TransferId: The unique DingConnect identifier for the transfer, used to cancel or look up a specific transfer.
    • DistributorRef: Your organization's own reference identifier for the transfer, if provided at the time of submission.
    • Status: The current state of the transfer (e.g., Submitted, Processing, Succeeded, Failed, Cancelled).
    • AccountNumber: The destination mobile account number that received the top-up.
    • SkuCode: The product SKU that was sent.
  • For reconciliation workflows, consider using this endpoint in a scheduled flow that runs daily to capture all transfers from the prior day and load them into your data warehouse or accounting system.

This endpoint retrieves all transfer records accessible to the authenticated account. If your organization requires filtering by date range, account number, or distributor reference, these filters can be applied after ingestion using Nexla's data transformation capabilities.

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.

Manual configuration​

Ding Connect data sources can also be manually configured to ingest data from any valid DingConnect API endpoint, including endpoints not covered by the pre-built templates, chained API calls, or custom request 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.

All DingConnect API v1 endpoints use the base URL https://api.dingconnect.com/api/V1/. The most common methods are GET for catalog, account, and status endpoints (e.g., GetCountries, GetProducts, GetBalance, GetProviderStatus) and POST for endpoints that accept request body filters (e.g., ListTransferRecords). For Path to Data, DingConnect list responses wrap records in a top-level Items array alongside pagination metadata (TotalItemCount, Skip, Take) — enter $.Items[*] to extract each record individually; for the Get Balance endpoint, which returns a single object, enter $ instead (or leave the field empty).

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 Ding Connect 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.

Use as a destination​

Click the + icon on the Nexset that will be sent to the Ding Connect destination, and select the Send to Destination option from the menu. Select the Ding Connect connector from the list of available destination connectors, then select the credential that will be used to connect to the Ding Connect account, and click Next; or, create a new Ding Connect credential for use in this flow.

Endpoint templates​

Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Ding Connect 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.

Send Transfer

Executes a mobile top-up or airtime transfer to a recipient's mobile account. This is the primary write operation in the DingConnect API and is used to deliver prepaid recharges to mobile subscribers across 190+ countries. Use this endpoint when your Nexset contains transfer requests — each record should include the product SKU, recipient account number, and the send or receive value.

  • Ensure the Nexset being sent to this destination contains the following required fields for each transfer record:

    • SkuCode: The product SKU code identifying the specific top-up product to send. This value must come from the DingConnect product catalog — use the List Products data source endpoint to retrieve valid SKU codes. Do not attempt to guess or construct SkuCodes manually.
    • AccountNumber: The destination mobile phone number of the recipient, including the international country dialing code (e.g., +447911123456 for a UK mobile number).
    • SendValue or ReceiveValue: The amount of the transfer. Provide either the amount in the distributor's send currency (SendValue) or the amount the recipient should receive in their local currency (ReceiveValue). Only one of these two fields is required per transfer record.
    • DistributorRef: A unique reference string that your organization assigns to this transfer for reconciliation purposes. This value is stored by DingConnect and can be used to look up the transfer record later. It must be unique per transfer — a common pattern is to use a UUID or a combination of date and internal order ID.

  • The following optional fields can also be included in each transfer record:

    • ValidateOnly: Set to true to perform a validation-only run. When enabled, DingConnect will validate the transfer parameters and return an indication of whether a live transfer would succeed, without actually executing the transfer or charging your account. This is useful for testing your data pipeline before enabling live transfers.
    • Settings: An optional object for additional provider-specific transfer settings. Consult the DingConnect API documentation for details on provider-specific settings that may be applicable to your use case.
  • DingConnect processes Send Transfer requests synchronously with a maximum processing time of 90 seconds. If the transfer has not been completed within 90 seconds, DingConnect will return a ProviderTimedOut status. In this case, the transfer may still complete asynchronously — use the List Transfer Records data source endpoint to check the final status of timed-out transfers before retrying.

The DistributorRef field must be unique for each transfer. Submitting a duplicate DistributorRef will cause DingConnect to reject the transfer request. Ensure your Nexset transformation logic generates a unique reference value for every record before sending it to this destination.

Cancel Transfers

Cancels one or more previously submitted transfers that have not yet been processed by DingConnect. This endpoint is specifically for cancelling transfers in batch mode that are in a "Submitted" state (i.e., queued but not yet executed by the provider). Use this endpoint when your workflow needs to revoke pending transfers — for example, when a downstream system cancels an order before the transfer is fulfilled.

  • Ensure the Nexset being sent to this destination contains the following field for each cancellation request:

    • TransferId: The unique DingConnect transfer identifier for the transfer to be cancelled. This value is returned when a transfer is submitted via Send Transfer and is also available in the List Transfer Records data source endpoint. Only transfers that are in "Submitted" (batch-pending) state can be cancelled — transfers that are already processing or completed cannot be reversed.
  • The request body is an array of cancellation request objects, each containing the TransferId of the transfer to cancel. Nexla will send the Nexset records to this endpoint as a JSON body according to the DingConnect Cancel Transfers API specification.
  • DingConnect will return a response for each cancellation request indicating whether the cancellation was accepted. Use the List Transfer Records data source endpoint after cancellation to confirm that the transfer status has been updated to "Cancelled".

Only transfers in "Submitted" (batch-pending) state can be cancelled. Transfers that have already been sent to a provider for processing cannot be cancelled through this endpoint. For failed or provider-timed-out transfers, contact DingConnect support.

Estimate Prices (Read-Only Compute)

Submits price estimation requests to the DingConnect API and returns the calculated rates and fees for a given product and transfer amount. This endpoint has no side effects — it does not execute a transfer or charge your account. It is modelled as a destination in Nexla because it accepts a POST request body. Use this endpoint to pre-calculate the cost of transfers before committing to them, or to populate pricing data in downstream systems.

  • Ensure the Nexset being sent to this destination contains the following fields for each estimation request:

    • SkuCode: The product SKU code for which you want to estimate the price. Retrieve valid SKU codes from the List Products data source endpoint.
    • SendValue or ReceiveValue: The amount to use as the basis for the price estimate. Provide either the send amount in the distributor's currency (SendValue) or the receive amount in the recipient's local currency (ReceiveValue).
  • The DingConnect API will return the estimated send value, receive value, exchange rate, and any applicable fees for each estimation request. This data can be captured by enabling the Response Webhook option (in the Manual configuration section below) so that Nexla automatically routes the API response into a new Nexla data source for further processing.

This endpoint is read-only and has no side effects. It does not deduct from your account balance or execute any transfers. It is safe to use for testing and pricing calculations without affecting your live DingConnect account.

Manual configuration​

Ding Connect destinations can also be manually configured to send data to any valid DingConnect 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.

All DingConnect write endpoints use the base URL https://api.dingconnect.com/api/V1/ with the POST method and JSON (application/json) content format. Enabling the Response Webhook option is especially recommended for the Send Transfer endpoint, as it lets Nexla automatically capture DingConnect's transfer confirmation or error response in a new Nexla webhook data source in real time, rather than requiring a separate poll of the List Transfer Records endpoint.

Important

When testing the Send Transfer endpoint, set the ValidateOnly field to true in your sample payload to perform a dry-run validation without executing a live transfer or charging your DingConnect account balance.

Save & activate​

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 the configured Ding Connect endpoint, open the destination resource menu, and select Activate.

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