Tech Partners: DDx Exchange as a Destination

Overview

This section covers information about Interactions API requests with the DDx Exchange's endpoint as a destination for Interactions API data.

Interactions App

Check out our Set Up for Sources section if you do not already have an Interactions API App required for sending data to the DDx Exchange.

Validating DDx API Key configuration

The /v1/auth/me endpoint enables two things:

1. Confirmation that you're using your API key correctly and can authenticate to the API
2. The ability to confirm the API Key's associated Workspace, Source and Destination details.

Additional API Request Validation

Interactions API requests using an API key configured with DDx Exchange as a Destination are subjected to additional validation. This includes:

1. Interactions matched and unmatched to a voter file now may be assessed for credits. For voter file-matched interactions, the person array must include at least one object with type of dwid, voterbase_id, smartvan_vanid, votebuilder_vanid or av_vanid. If an interaction is not matched to a voter file, the interaction must include at least one object in the person array and some form of PII. PII may be included in channel with a type of phone_number, address, email, or social_handle, or within the contactInfo object. For voter file-unmatched interactions, PII must be submitted or they will be considered unsupported.
2. All survey response outcomesDetailed objects (indicated by the "survey_response" type) must include questionId and responseId. These must be valid VAN survey question and response IDs and must be integers if Exchange is a Destination.
3. All survey response outcomesDetailed objects (indicated by the "survey_response" type) must include questionText and responseText. These should be the full text of the question and response, respectively.
4. All event signup outcomesDetailed objects (indicated by the "event_signup" type) must include an event_id object
   and a status object with a valid status.
5. delete operations within an interaction will not be sent to the Exchange; these are unsupported. Other parts of the same interaction with outcomesDetailed.operation = create will still be submitted to the Exchange.

An example request can be found on the API Examples page (Scenario 3). Note its person array uses none of the types above, so as written it would not be assessed for credits.

How is data mapped to the DDx Exchange schema?

The table below describes how data on the Interactions API request is mapped to the format accepted by the DDx Exchange. Currently, language and is_cell fields are not supported and will always be reported to the Exchange as null.

Dispositions

Survey Responses

Survey Response Metadata

Unmatched Dispositions

Unmatched Survey Responses

Fetching DDx Exchange transactional logs

Status and logs regarding integration with the DDx Exchange can be fetched three ways:

1. By date, using the endpoint described here. The date range is capped at 30 days, and results are paginated (100 per page by default, 1000 maximum).
2. By interactionId, which can be found under acceptedInteractions.data[].interactionId in POST /interactions responses, using the endpoint described here.
3. By correlationId, the batch identifier returned in every POST /interactions response and the X-Correlation-Id header.