An example: a request originating in an existing CRM
A CRM may hold the customer relationship while a correspondence service handles an approved letter. Decide which system supplies the recipient details, which one identifies the final document and where the relevant status needs to be displayed. Retain the references needed to connect the records in both directions.
Then consider an ordinary failure: the connection is interrupted after a request is submitted, so the CRM tries again. The integration needs a way to recognise the same intended action rather than create another dispatch unintentionally. Explain these retry and ownership questions when discussing an integration with Epistles. Public pages are planning guidance, not a published production API contract. Endpoint details, authentication, event formats and availability need to be confirmed through the implementation process before a connection is built.
Keep external systems connected without losing control
Organisations may already use a CRM, ERP, accounting system or case-management platform. An integration should be able to create or retrieve authorised correspondence records without moving confidential data through uncontrolled channels. API keys need restricted scopes, event delivery must be verifiable, and automated requests should be idempotent so retries do not accidentally generate duplicate letters.
The external system may initiate an action, but Epistles should remain clear about which document was finalised and which delivery operations actually occurred. Webhooks and status updates should preserve event timestamps and sources. The interface should also make it possible for administrators to revoke a connection without affecting unrelated tenant data.