Find the relevant record
Open or identify a customer record when the target API supports reliable search and the calling data is suitable for matching.
Integrations & Automation
Heritage can build and maintain an integration when the target system provides usable API documentation and customer-authorized access. The work begins by confirming that the required data and actions are actually available.
No implied compatibility: This page describes integration patterns and evaluation criteria. It does not claim that a named third-party system is currently live or supported.
Actual behavior depends on the phone service, target API, permissions, and approved workflow.
Event to action
These are defensible workflow patterns, not a promise that every target system exposes the required event, field, or action.
Open or identify a customer record when the target API supports reliable search and the calling data is suitable for matching.
Add approved call details to a customer timeline when the destination exposes the required record and activity functions.
Create a ticket, task, or team notification so an agreed workflow can continue outside the phone system.
Send an approved outcome, recording link, transcript link, or follow-up trigger only when the related service is configured and the destination permits it.
Check a verified scheduling connection, offer eligible times by SMS, and record a confirmed selection under the configured appointment and fallback rules.
Review the scheduling agentClassification before commitment
Heritage uses clear classifications so an evaluation is not mistaken for a production-ready integration. No named integrations are listed today.
View the integration directoryEvaluation process
Define the triggering event, intended action, people involved, and acceptable exception path.
Confirm documented authentication, required endpoints or events, stable identifiers, permissions, and relevant limits.
Identify the minimum fields needed and verify that both systems can read or write them as required.
Agree who authorizes access, administers credentials, owns third-party accounts, and approves changes.
Validate expected events, duplicate handling, errors, and representative exceptions before operational use.
Establish how vendor changes, access failures, workflow changes, and support requests will be handled.
Commercial boundary
Standard supported integrations do not carry a separate initial Heritage build fee; a recurring integration charge applies. Third-party API, licensing, professional-services, or marketplace fees remain separate.
Data migration, historical cleanup, and unusually large custom applications are separate from a standard operational integration. Heritage confirms scope before work begins; this page publishes no price or tier.
Common questions
Heritage can evaluate a system when usable API documentation and customer-authorized access are available. The required data and functions must exist, and API stability, rate limits, permissions, and vendor rules may constrain the result.
Standard supported integrations do not carry a separate initial Heritage build fee. A recurring integration charge applies, and third-party fees remain separate. Custom applications, migration, and historical cleanup require separate scope.
No. It describes the evaluation and classification model. A named system should not be treated as live or supported until Heritage confirms its status, capabilities, requirements, limitations, and support relationship.
Bring the business event, desired action, target-system name, API documentation, account-owner contact, and known vendor requirements. Do not submit credentials through the website form.