Connecting Chorus

N.B. Chorus is classified as a "Custom API Connection" due to the flexibility required, so it is requires a bit of extra handoff compared to our standard connectors. In addition, there are substantial inaccuracies in the Chorus API documentation following their ZoomInfo acquisition; we have worked around these in the process of developing the connector.

Customer shares a Chorus API key with Frame.
1. Your Chorus Admin retrieves an API key.
2. Your Chorus Admin shares the API key with Success team via your preferred secret sharing method. Frame engineering stores this key in Amazon KMS. Examples:
  1. Secure Gsheet
  2. Keybase
  3. 1password
  4. Lastpass
Frame Success registers the Chorus connector in Frame.
1. API keys are stored in AWS KMS.
The connector periodically polls the Chorus engagements endpoint to discover new conversations.
1. Polling period can be set based on latency goals, typically 10m or 1h.
2. Since Chorus cannot provide an exactly-once iterator of conversations, we poll overlapping periods and deduplicate to minimize risk of missed conversations.
3. At a customer's request, Frame can backfill prior data by setting the processing start date to be in the past. Note this uses more API calls to complete.
Any new conversations are expanded using the conversations endpoint to retrieve text utterances.
Re-identification of users / accounts is done via email associated with “participants” in the Chorus engagements.
1. We have some ability to modify the connector to utilize other profile fields if Chorus is configured to retrieve those.

It is typical during implementation to identify details of how a customer is using Chorus that require tuning of the adapter – for example if emails are rarely available, etc. Optimizing against those constraints is part of the collaboration with Frame technical success staff.

ZoomInfo does not publish Chorus-specific rate limits, but the connector is frugal, requiring only one call for each polling and another for each engagement.