Create contact records from CSV

Creates contact records from a CSV file. It imports the CSV text with a header row that specifies the order of these required columns:

A contact might require one or more rows of CSV text to describe it. There is one row for each treatment to be considered. A contact can include more than one treatment. The information in the columns from responseTrackingCode to pathTraversed are repeated. The columns from treatmentId to responseChannel contain unique information per row.

CSV text that is obtained by the counterpart GET action can be used here. The GET action includes an ID column in the output. The import ignores the ID value and a new ID is generated for each contact. Importing the CSV text that is obtained by CSV exporting on the same deployment is not successful because there is a uniqueness constraint violation in the response tracking code value.

In the objectVariables column, each name, value, dataType tuple in the array is represented as a triple tilde separated string and each tuple is separated by a semicolon. The strings cannot contain semicolons.

The responseTrackingCode column cannot be blank.

If the contact already exists, the unique information columns on the rows are used to update the contact. The other columns must carry information identical to what is already recorded. If this condition is not met, the update is rejected.

These are the immutable columns: creationTimeStamp responseTrackingCode subjectId subjectLevel objectUri objectRevisionId objectType objectVariables receiverId receiverRole channel ruleFired pathTraversed abTests treatmentId treatmentRevisionId treatmentGroupId treatmentGroupRevisionId objectNodeId

The input CSV is processed in the order it is received. All contiguous rows with the same responseTrackingCode are considered one section. Those rows are processed according to the description above. It is possible to have the same responseTrackingCode in non-consecutive sections. In that case, the subsequent section is considered updating the contact from the previous section. The service tries to process as many rows as possible.

The output is a multipart/mixed response body. The boundary string of each part is identified in the Content-Type response header. There are three parts in this response.

The first part is for the accepted CSV (header Content-ID: Accepted-CSV). Each contact that was successfully processed is included here. As soon as a contact is created, its rows are streamed back.

The second part is for the rejected CSV (header Content-ID:Rejected-CSV). Each contact that failed processing is identified here. It is in CSV format with the following column order: record number in the entire CSV input, the columns from the input row, and error message. If one line of text has error, all the lines for that contact are rejected. This API prints the first line of the rejected text.

The third part is for global issues (header Content-ID: Global-Issue). It is in CSV format with the following column order: responseTrackingCode or the asterisk value (i.e wildcard for all contacts), global error message that conveys the error that prevents any CSV processing. An example would be the lack of permissions.