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.
- Your Chorus Admin retrieves an API key.
- 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:
- Secure Gsheet
- Frame Success registers the Chorus connector in Frame.
- API keys are stored in AWS KMS.
- The connector periodically polls the Chorus engagements endpoint to discover new conversations.
- Polling period can be set based on latency goals, typically 10m or 1h.
- Since Chorus cannot provide an exactly-once iterator of conversations, we poll overlapping periods and deduplicate to minimize risk of missed conversations.
- 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.
- 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.
Updated 3 months ago