Skip to main content

Dixa 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 Dixa location.
dixa_api.png

Dixa

Create a Dixa Destination​

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

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

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

    Dixa destinations can also be configured manually, allowing you to send data to Dixa endpoints not included in the pre-built templates or apply further customisations 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 Dixa API endpoints. Each template is designed specifically for the corresponding Dixa 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 Conversation

    Create a new inbound conversation in Dixa. Use this endpoint to programmatically open a conversation from an external system — for example, when a customer submits a form in a third-party CRM, e-commerce platform, or backend service, and you want to create a corresponding support conversation in Dixa automatically.

    • No additional template parameters are required. The Nexset data will be sent as a JSON request body to https://dev.dixa.io/v1/conversations using a POST request. Map the fields in your Nexset to the Dixa conversation schema before activating the destination.
    • Required fields for the Dixa Create Conversation API include the conversation channel type and end user details. Refer to the Dixa API reference for the full request body schema.

    Full API reference and request body schema for this endpoint is available at docs.dixa.io/openapi/dixa-api/v1/conversations.

    Close Conversation

    Close a conversation by its unique ID. This is a standard lifecycle action used in automated resolution workflows — for example, automatically closing conversations after a self-service resolution, a set period of inactivity, or when a downstream system confirms that an issue has been resolved.

    • Enter the unique identifier of the conversation to close in the Conversation ID field. This is a required parameter. The Conversation ID should be mapped from your Nexset data — for example, from a prior Dixa data source or a CRM record that stores the Dixa conversation reference.
    • The close operation is sent as a PUT request to https://dev.dixa.io/v1/conversations/{'{conversationId'}/close.

    Full API reference for this endpoint is available at docs.dixa.io/openapi/dixa-api/v1/conversations.

    Post Conversation Message

    Post a message into an existing Dixa conversation. Use this endpoint to send automated replies, notifications, or system-generated messages into an open conversation — for example, sending an order status update into a conversation when a fulfilment event occurs in your e-commerce platform.

    • Enter the unique identifier of the conversation in which you want to post a message in the Conversation ID field. This is a required parameter.
    • The message content and metadata will be sent as a JSON request body to https://dev.dixa.io/v1/conversations/{'{conversationId'}/messages using a POST request. Map the relevant fields from your Nexset to the Dixa message schema.

    Create Conversation Note

    Post an internal note on a Dixa conversation. Internal notes are visible only to agents and are used to provide context, escalation details, or follow-up instructions. Use this endpoint to enrich Dixa conversations with metadata from external systems — for example, appending a CRM record link, a fraud check result, or a fulfilment status note.

    • Enter the unique identifier of the conversation to attach the note to in the Conversation ID field. This is a required parameter.
    • The note content will be sent as a JSON request body to https://dev.dixa.io/v1/conversations/{'{conversationId'}/notes using a POST request.

    Claim Conversation

    Claim (assign) a conversation to a specific agent. Use this endpoint in automated assignment workflows — for example, routing high-priority conversations to dedicated agents based on customer tier, or assigning conversations to agents identified through an external matching system.

    • Enter the unique identifier of the conversation to claim in the Conversation ID field. This is a required parameter.
    • The request body can include an optional force flag to override an existing agent assignment. Include the agent ID and any additional parameters in your Nexset data, which will be sent as the JSON request body.
    • The claim operation is sent as a PUT request to https://dev.dixa.io/v1/conversations/{'{conversationId'}/claim.

    Transfer Conversation Queue

    Transfer a conversation to a different Dixa queue. This is a core operational action used in workflow automation — for example, re-routing a conversation to a specialist queue when an automated classification system determines it requires a different team.

    • Enter the unique identifier of the conversation to transfer in the Conversation ID field. This is a required parameter.
    • Include the target queue ID and any additional routing parameters in your Nexset data, which will be sent as the JSON request body. The transfer operation is sent as a PUT request to https://dev.dixa.io/v1/conversations/{'{conversationId'}/transfer/queue.

    Transfer Conversation to Agent

    Transfer a conversation directly to a specific agent (rather than to a queue). Use this endpoint for agent-level routing automation — for example, returning a conversation to a customer's dedicated account manager or escalating to a senior agent based on external criteria.

    • Enter the unique identifier of the conversation to transfer in the Conversation ID field. This is a required parameter.
    • Include the target agent ID in your Nexset data, which will be sent as the JSON request body. The transfer operation is sent as a PUT request to https://dev.dixa.io/v1/conversations/{'{conversationId'}/transfer/agent.

    Update Conversation Custom Attributes

    Update custom attribute values on a specific conversation. Custom attributes allow you to store organisation-specific data fields on conversations. Use this endpoint to enrich conversation records with data from external systems — for example, setting a "customer tier" attribute from your CRM, or marking conversations with order values from your e-commerce platform.

    • Enter the unique identifier of the conversation whose custom attributes you want to update in the Conversation ID field. This is a required parameter.
    • The custom attribute key-value pairs should be included in your Nexset data, which will be sent as the JSON request body. The update is performed as a PATCH request to https://dev.dixa.io/v1/conversations/{'{conversationId'}/custom-attributes.

    Custom attributes must be defined in your Dixa organisation settings before values can be written to them. Refer to your Dixa administrator to confirm which custom attributes are available.

    Offer Conversation Rating

    Trigger a CSAT (Customer Satisfaction) or NPS (Net Promoter Score) rating offer for a conversation. Use this endpoint to automate post-conversation feedback collection — for example, automatically sending a rating request after a conversation is closed or after a resolution milestone is reached in an external workflow.

    • Enter the unique identifier of the conversation for which you want to offer a rating in the Conversation ID field. This is a required parameter.
    • The rating offer is sent as a POST request to https://dev.dixa.io/v1/conversations/{'{conversationId'}/ratings/offer. Include any required rating configuration in your Nexset data request body.

    Submit Conversation Rating

    Submit a CSAT or NPS rating result for a conversation. This endpoint closes the rating workflow initiated by the Offer Conversation Rating endpoint — use it to record rating responses collected through an external survey or feedback system and write them back to the corresponding Dixa conversation.

    • Enter the unique identifier of the conversation the rating belongs to in the Conversation ID field. This is a required parameter.
    • Enter the rating offer ID returned by the Offer Conversation Rating endpoint in the Rating ID field. This is a required parameter.
    • The rating submission is sent as a POST request to https://dev.dixa.io/v1/conversations/{'{conversationId'}/ratings/{'{ratingId'}/submit. Include the rating value and any optional comments in your Nexset data request body.

    Tag Conversation

    Apply an existing tag to a conversation. Tags are used in Dixa to categorise conversations for routing, reporting, and quality assurance. Use this endpoint in automated workflows to apply tags based on external classification results — for example, tagging a conversation with a topic category determined by an AI classifier.

    • Enter the unique identifier of the conversation to tag in the Conversation ID field. This is a required parameter.
    • Enter the unique identifier of the tag to apply in the Tag ID field. This is a required parameter. Tag IDs can be obtained from the List Tags data source endpoint. The tag is applied as a PUT request to https://dev.dixa.io/v1/conversations/{'{conversationId'}/tags/{'{tagId'}.

    Untag Conversation

    Remove a tag from a conversation. Use this endpoint as the counterpart to Tag Conversation — for example, removing a "pending review" tag once a conversation has been reviewed, or re-classifying a conversation by removing an incorrect tag.

    • Enter the unique identifier of the conversation from which you want to remove the tag in the Conversation ID field. This is a required parameter.
    • Enter the unique identifier of the tag to remove in the Tag ID field. This is a required parameter. The untag operation is sent as a DELETE request to https://dev.dixa.io/v1/conversations/{'{conversationId'}/tags/{'{tagId'}.

    Create End User

    Create a new end user (customer) record in Dixa. Use this endpoint to provision customer profiles in Dixa from external systems — for example, when a new customer registers in your e-commerce platform, CRM, or loyalty programme and you want to create a corresponding Dixa contact automatically.

    • No additional template parameters are required. The Nexset data will be sent as a JSON request body to https://dev.dixa.io/v1/endusers using a POST request. Map the relevant customer fields from your Nexset to the Dixa end user schema.
    • Required fields typically include the end user's name and at least one contact method (email address or phone number). Refer to the Dixa API reference for the full required schema.

    Full API reference and request body schema for this endpoint is available at docs.dixa.io/openapi/dixa-api/v1/endusers.

    Update End User

    Replace an end user's profile data with a full PUT update. Use this endpoint to synchronise customer profile changes from an external CRM or identity system to Dixa — for example, updating a customer's name, email, or phone number when they change their details in your primary customer database.

    • Enter the unique identifier of the end user record to replace in the User ID field. This is a required parameter. User IDs can be obtained from the List End Users or Get End User data source endpoints.
    • The complete updated user profile will be sent as a JSON request body to https://dev.dixa.io/v1/endusers/{'{userId'} using a PUT request. All fields in the profile will be replaced — include all fields, not just the changed ones.

    Update End User Custom Attributes

    Update custom attribute values for a specific end user. This is the primary enrichment write path from external CRMs — use it to store organisation-specific customer data on Dixa end user records, such as customer tier, loyalty points balance, account manager name, or lifetime value.

    • Enter the unique identifier of the end user whose custom attributes you want to update in the User ID field. This is a required parameter.
    • The custom attribute key-value pairs should be included in your Nexset data, which will be sent as the JSON request body. The update is performed as a PATCH request to https://dev.dixa.io/v1/endusers/{'{userId'}/custom-attributes.

    Custom attributes must be defined in your Dixa organisation settings before values can be written to them. Refer to the Dixa API reference at docs.dixa.io/openapi/dixa-api/v1/endusers for full schema details.

    Anonymize End User

    Anonymize an end user record as a soft-delete operation — GDPR right-to-erasure (right-to-be-forgotten) workflows. The record is not destroyed; instead, personally identifiable information (PII) is replaced with anonymised values while the structural record is preserved for referential integrity. Use this endpoint in data governance automation workflows triggered by deletion requests from your data management or privacy compliance system.

    • Enter the unique identifier of the end user to anonymise in the User ID field. This is a required parameter.
    • The anonymisation is performed as a PATCH request to https://dev.dixa.io/v1/endusers/{'{userId'}/anonymize with an empty request body.

    :::warning Important Anonymisation is irreversible. Once an end user's PII has been anonymised, it cannot be restored. Ensure your workflow includes appropriate verification steps before executing this endpoint in production. :::

    Create Agent

    Create a new agent or administrator in the Dixa organisation. The primary automation use case is agent onboarding — use this endpoint to provision new agent accounts automatically when a new employee is added to your HR system or identity provider, reducing manual setup time.

    • No additional template parameters are required. The Nexset data will be sent as a JSON request body to https://dev.dixa.io/v1/agents using a POST request. Map the relevant agent profile fields from your Nexset to the Dixa agent schema.
    • Required fields typically include the agent's name, email address, and role. Refer to the Dixa API reference for the full required schema.

    Full API reference and request body schema for this endpoint is available at docs.dixa.io/openapi/dixa-api/v1/agents.

    Update Agent

    Partially update an agent's profile using a PATCH request. Use this endpoint when you need to update specific agent attributes without replacing the full profile — for example, updating a display name, phone number, or role when the corresponding record changes in your HR system.

    • Enter the unique identifier of the agent to update in the Agent ID field. This is a required parameter. Agent IDs can be obtained from the List Agents data source endpoint.
    • Include only the fields to be updated in your Nexset data — these will be sent as the JSON request body in a PATCH request to https://dev.dixa.io/v1/agents/{'{agentId'}.

    Delete Agent

    Delete (deactivate) an agent from the Dixa organisation. Use this endpoint for agent offboarding automation — for example, automatically deactivating Dixa access when an employee record is marked as terminated in your HR system.

    • Enter the unique identifier of the agent to deactivate in the Agent ID field. This is a required parameter. Agent IDs can be obtained from the List Agents data source endpoint.
    • The deletion is performed as a DELETE request to https://dev.dixa.io/v1/agents/{'{agentId'}. No request body is required.

    Create Queue

    Create a new queue in Dixa. Use this endpoint for provisioning automation — for example, automatically creating queues when new product lines, regions, or service tiers are launched, based on configuration data in an external system.

    • No additional template parameters are required. The Nexset data will be sent as a JSON request body to https://dev.dixa.io/v1/queues using a POST request. Map the queue configuration fields from your Nexset to the Dixa queue schema.

    Full API reference and request body schema for this endpoint is available at docs.dixa.io/openapi/dixa-api/v1/queues.

    Update Queue

    Update queue details including name, description, and routing settings. Use this endpoint to synchronise queue configuration changes from an external system — for example, updating queue names or routing rules based on operational changes managed in a configuration management database.

    • Enter the unique identifier of the queue to update in the Queue ID field. This is a required parameter. Queue IDs can be obtained from the List Queues data source endpoint.
    • Include the fields to be updated in your Nexset data. The update is performed as a PATCH request to https://dev.dixa.io/v1/queues/{'{queueId'}.

    Delete Queue

    Delete a queue by its unique ID. Use this endpoint to clean up queues that are no longer needed — for example, when a product line or service tier is discontinued and its corresponding queue should be removed from Dixa.

    • Enter the unique identifier of the queue to delete in the Queue ID field. This is a required parameter. Queue IDs can be obtained from the List Queues data source endpoint.
    • The deletion is performed as a DELETE request to https://dev.dixa.io/v1/queues/{'{queueId'}. No request body is required.

    Add Queue Members

    Add one or more agents to a queue. Use this endpoint in workforce management automation — for example, dynamically assigning agents to queues based on shift schedules, skill updates, or staffing changes managed in an external HR or WFM system.

    • Enter the unique identifier of the queue to which you want to add members in the Queue ID field. This is a required parameter.
    • Include the agent IDs to be added in your Nexset data request body. The update is performed as a PATCH request to https://dev.dixa.io/v1/queues/{'{queueId'}/members.

    Remove Queue Members

    Remove one or more agents from a queue. Use this endpoint as the counterpart to Add Queue Members — for example, automatically removing agents from queues at the end of a shift, when they change roles, or during offboarding.

    • Enter the unique identifier of the queue from which you want to remove members in the Queue ID field. This is a required parameter.
    • Include the agent IDs to be removed in your Nexset data request body. The removal is performed as a DELETE request to https://dev.dixa.io/v1/queues/{'{queueId'}/members.

    Create Team

    Create a new team in the Dixa organisation. Teams group agents and link to queues to organise routing and reporting. Use this endpoint for provisioning automation — for example, automatically creating a Dixa team when a new support team is set up in your HR system.

    • No additional template parameters are required. The Nexset data will be sent as a JSON request body to https://dev.dixa.io/v1/teams using a POST request. Map the team configuration fields from your Nexset to the Dixa team schema.

    Full API reference and request body schema for this endpoint is available at docs.dixa.io/openapi/dixa-api/v1/teams.

    Update Team

    Update team metadata including name and description. Use this endpoint to synchronise team name changes from an external HR or organisational management system to Dixa.

    • Enter the unique identifier of the team to update in the Team ID field. This is a required parameter. Team IDs can be obtained from the List Teams data source endpoint.
    • Include the fields to be updated in your Nexset data. The update is performed as a PATCH request to https://dev.dixa.io/v1/teams/{'{teamId'}.

    Delete Team

    Delete a team by its unique ID. Use this endpoint to remove teams that are no longer active — for example, when a support team is dissolved or merged with another team.

    • Enter the unique identifier of the team to delete in the Team ID field. This is a required parameter. Team IDs can be obtained from the List Teams data source endpoint.
    • The deletion is performed as a DELETE request to https://dev.dixa.io/v1/teams/{'{teamId'}. No request body is required.

    Add Team Members

    Add agents or administrators to a Dixa team. Use this endpoint in onboarding and workforce management automation — for example, automatically adding a new agent to the appropriate teams based on their role or department in your HR system.

    • Enter the unique identifier of the team to which you want to add members in the Team ID field. This is a required parameter.
    • Include the agent or administrator IDs to be added in your Nexset data request body. The addition is performed as a POST request to https://dev.dixa.io/v1/teams/{'{teamId'}/members.

    Remove Team Members

    Remove agents or administrators from a Dixa team. Use this endpoint in offboarding and role-change automation — for example, automatically removing an agent from all teams when they leave the organisation or transfer to a different department.

    • Enter the unique identifier of the team from which you want to remove members in the Team ID field. This is a required parameter.
    • Include the agent or administrator IDs to be removed in your Nexset data request body. The removal is performed as a DELETE request to https://dev.dixa.io/v1/teams/{'{teamId'}/members.

    Create Tag

    Create a new conversation tag in the Dixa organisation. Use this endpoint to provision tags programmatically — for example, synchronising a tag catalogue from an external taxonomy or category management system into Dixa.

    • No additional template parameters are required. The Nexset data will be sent as a JSON request body to https://dev.dixa.io/v1/tags using a POST request. Map the tag name and any additional properties from your Nexset to the Dixa tag schema.

    Full API reference and request body schema for this endpoint is available at docs.dixa.io/openapi/dixa-api/v1/tags.

    Delete Tag

    Delete a conversation tag by its unique ID. Use this endpoint to clean up tags that are no longer in use — for example, removing deprecated category labels from Dixa when a taxonomy is updated in an external system.

    • Enter the unique identifier of the tag to delete in the Tag ID field. This is a required parameter. Tag IDs can be obtained from the List Tags data source endpoint.
    • The deletion is performed as a DELETE request to https://dev.dixa.io/v1/tags/{'{tagId'}. No request body is required.

    Create Webhook Subscription

    Register a new webhook subscription to receive real-time conversation and event notifications from Dixa. Use this endpoint to programmatically configure webhooks — for example, registering a Nexla webhook source URL so that Dixa event data is automatically pushed into your data pipeline in real time.

    • No additional template parameters are required. The webhook configuration (including the target URL and the event types to subscribe to) will be sent as a JSON request body to https://dev.dixa.io/v1/webhooks using a POST request.
    • Before creating a webhook, use the List Webhooks data source endpoint to check whether a subscription with the same URL already exists, to avoid duplicate registrations.

    Full API reference and request body schema for this endpoint is available at docs.dixa.io/openapi/dixa-api/v1/webhooks.

    Update Webhook

    Update an existing webhook subscription's URL, subscribed event types, or enabled state. Use this endpoint when webhook endpoint URLs change or when you need to modify the set of events a subscription listens to.

    • Enter the unique identifier of the webhook subscription to update in the Webhook Subscription ID field. This is a required parameter. Webhook subscription IDs can be obtained from the List Webhooks data source endpoint.
    • Include the fields to be updated in your Nexset data. The update is performed as a PATCH request to https://dev.dixa.io/v1/webhooks/{'{webhookId'}.

    Delete Webhook

    Delete (deregister) a webhook subscription. Use this endpoint to clean up stale or obsolete webhook subscriptions — for example, removing a subscription when the target endpoint is decommissioned or when a Nexla flow is archived.

    • Enter the unique identifier of the webhook subscription to delete in the Webhook Subscription ID field. This is a required parameter. Webhook subscription IDs can be obtained from the List Webhooks data source endpoint.
    • The deletion is performed as a DELETE request to https://dev.dixa.io/v1/webhooks/{'{webhookId'}. No request body is required.

    Query Analytics Metrics

    Query and compute analytics metrics with filters, dimensions, and time ranges using a POST request with a structured body. This is the primary aggregated KPI read-and-write path — use this endpoint when you need to compute specific Dixa metrics on demand from within a data flow, such as pulling aggregated performance data into a reporting database.

    • No additional template parameters are required. The query body (including metric IDs, filters, dimensions, and time range) will be sent as a JSON request body to https://dev.dixa.io/v1/analytics/metrics using a POST request.
    • Use the List Analytics Metrics data source endpoint to discover available metric IDs before constructing your query body.

    Full API reference and request body schema for this endpoint is available at docs.dixa.io/openapi/dixa-api/v1/analytics.

    Query Analytics Records

    Query raw conversation and interaction records with filters and time ranges using a POST request with a structured body. This endpoint provides filtered-record retrieval for reporting use cases where you need record-level data rather than aggregated metrics — for example, exporting specific conversation records matching defined criteria into a data warehouse.

    • No additional template parameters are required. The query body (including filters and time range) will be sent as a JSON request body to https://dev.dixa.io/v1/analytics/records using a POST request.

Configure Manually​

Dixa destinations can be manually configured to send data to any valid Dixa API endpoint. Manual configuration provides maximum flexibility for sending data to endpoints not covered by pre-built templates or when you need custom request body formatting, dynamic URL parameters, or advanced response handling.

Using manual configuration, you can also configure Nexla to automatically send the response received from the Dixa 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 Dixa API from the Method pulldown menu. Common Dixa API write methods include:

    • POST: For creating new resources (conversations, end users, agents, queues, teams, tags, webhooks)
    • PUT: For replacing or updating existing resources (closing conversations, claiming conversations, queue transfers)
    • PATCH: For partial updates (updating agent profiles, queue settings, end user custom attributes)
    • DELETE: For removing resources (deleting agents, queues, tags, webhook subscriptions)

Data Format​

  1. Select the format in which the Nexset data will be sent to the Dixa API from the Content Format pulldown menu. Nexla will automatically convert the data to the selected format for each API call. The Dixa API accepts JSON (application/json) for all write operations.

API Endpoint URL​

  1. Enter the URL of the Dixa API endpoint to which you want to send the Nexset data in the URL field. The Dixa API base URL is https://dev.dixa.io/v1/. For update or delete operations on specific resources, append the resource ID at the end of the URL (for example, https://dev.dixa.io/v1/agents/{agentId}).

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 the Authorization header or any other headers already present in the Dixa credential. The API key configured in your credential is automatically applied to every request.

Exclude Attributes from the Call​

Optional

  • If any record attributes in the Nexset should be omitted when sending data to this Dixa 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.

Most Dixa API write endpoints accept a single record per request. Record batching is most useful with Dixa analytics query endpoints that support array-structured request bodies. Review the Dixa API documentation for the specific endpoint to confirm whether batch requests are supported before enabling this option.

Response Webhook​

Optional

Nexla can automatically send the response received from the Dixa 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 newly created conversation ID or agent ID returned by Dixa after a create operation.

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

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