We have several use cases in my organization where API integration from top to bottom is the most desirable approach. In these instances the consumers use the APIs to distribute surveys AND gather the response data using the export APIs. As such, the actual Qualtrics contacts and all the associated IDs are mostly meaningless overhead to these consumers. To simplify this process, I've been doing proof of concept around leveraging Actions to distribute surveys and API event subscriptions to gather completed survey response data close to real-time rather than having to run CRON jobs to export responses every so often. I LOVE this idea because our API consumers no longer have to concern themselves with managing mailing list IDs, contact IDs, library IDs, message IDs, subject IDs etc. and they don't have to write complicated CRON jobs for ETL. Instead they can simply provision a URI from the JSON action event, define their own JSON payload, map the fields as required and kick off a task to distribute the survey via email invitation. By having a public facing endpoint of our own that Qualtrics calls into on every survey completion (web hook), the overhead is significantly reduced. In this scenario the developers and business partners can leverage Qualtrics with nearly zero direct interaction with the user interface and only have to know their API token and a couple of endpoints (no more ID overload). Also, in these use cases the Qualtrics contacts are of very little concern to the consumer and they have their own analytics systems to process and report against the completion data so they simply don't have a need to be active in the user interface.



However, there are 2 issues/limitations with the survey distribution in this scenario that I'm hoping to get feedback over:



1. When utilizing the survey invitation task, there doesn't appear to be a way to provide translations for the invitation email you define in the task. You can choose a subject from the library but not an invitation email. Unless I'm missing something, this means that I'd have to create a unique action (and URI) per language even though they would all be distributing the same survey. I really hate that idea and hope there's a way to actually specify either an invitation email from the library or to provide translations in the task definition.



2. I don't see a way to know when an invitation email has been bounced in this scenario. The Actions reporting menu will still have a green check box next to the email step even if the email was bounced. But because you're not leveraging the APIs directly, there is no record of the distribution under "Distributions" where you'd normally be able to tell if the invitation email was bounced or was a duplicate. We commonly have cases where the same survey needs to be distributed to the same individual multiple times and we change the context of the surveys by updating the embedded data for each call and then carry that into the survey (Ex. "Employee Assessment" survey regarding employees 1, 2, 3, 4 etc. all need to go to supervisor "Ryan").



If you have feedback about either hangup, I'd love to hear it!



EDIT: Yikes, it may be worse even than I thought. Since testing the Action using a call that would have created a "duplicate" in other approaches, the "Email Survey Distribution Step" (under Actions > Reporting) doesn't even attempt to fire anymore. No bueno.