Integrations · Bitrix24 · TrustMe · e-signature
TrustMe e-signature integration
Client:
sattar.kz
Category: Integrations
Stack: Bitrix24 Smart Process, TrustMe API, PHP, webhook, cURL
Timeline: 2–4 weeks
sattar.kz
Category: Integrations
Stack: Bitrix24 Smart Process, TrustMe API, PHP, webhook, cURL
Timeline: 2–4 weeks
Problem
Sending contracts for e-signature was implemented separately on several CRM portals: no shared storage of signing status and no protection of the webhook against re-processing.
Constraints
Different smart processes and field sets on each portal, the need not to lose status on repeated webhooks, secrets that could not stay in the code.
What I did
- A "send for signature" action right from the deal card
- Receiving the signing status via a protected webhook
- Audit of the existing integration: a map of data flows and failure points
- Moving the logic into a separate module — API client, service, handlers, status storage
- Idempotent handling of repeated webhook deliveries
Screenshots
Screenshot coming soon
The "send for signature" button on the deal card
Screenshot coming soon
Signing status on the deal card after the webhook responds
Screenshot coming soon
History of signing statuses
Architecture
Bitrix24 Smart Process
→ TrustMe Client
→ Webhook Handler
→ Status storage
→ CRM fields/comments
Result
E-signature stopped being a set of similar scripts scattered across portals: the integration got a single architecture, a status history, and a webhook that no longer fears redelivery.
What can be reused
TrustMe API client
Idempotent webhook handler
Signing-status storage layer
Approach to auditing and migrating a legacy integration