A message appearing in the CRM is only the start of an integration check. The reply must leave from the right account, the PDF must remain readable, and a restart must not send old messages to the customer again.
The setup brings together 20 regular MAX accounts. On 22 October, KMVSG tested a dedicated pilot route with Bitrix24 Open Channels using an agreed pair of accounts. Here is what the test established and which scenarios still need acceptance testing.
Verified pilot
From a message to a confirmed reply
- 01Account
- 02Conversation
- 03Reply
- 04Verification
- The account and external conversation determine the CRM route.
- The PDF is checked after receipt at the destination.
- Recovery is checked for additional sends.
Separate accounts before importing conversations
The pilot uses separate Open Channels with one agreed agent. Personal and group conversations have their own mappings. Even two representations of the same group retain their source-account identity.
Chat names help people navigate, but routing needs stable account and conversation identifiers. This ensures a reply comes from the correct account when contacts have matching names. Existing production channels were not reconfigured for this test.
Test an actual agent reply from the Open Channel
Bitrix24 documentation describes a custom Open Channel connector: an external message is submitted with sender and chat data, and the application receives identifiers for the created conversation. Acceptance testing must also cover the return route from the normal agent interface.
The agreed pair exchanged a real text message from MAX and a reply from Bitrix24. The other MAX account recorded the reply exactly once. Actual delivery and read events were checked separately. A conversation read receipt does not prove that the PDF contents were viewed.
Download the PDF at both ends
An attachment icon only confirms that a message contains a file. In our test, a PDF travelled from MAX to Bitrix24 Drive and back from the standard CRM interface to MAX. We read the received bytes at each destination and compared their SHA-256 checksums with the original.
Matching checksums verified the integrity of that particular test PDF in both directions. A small-document test does not establish the size limit for every attachment or verify voice and video playback.
Restart without repeating the conversation
The gateway retains the relationship between the source event, send operation and result. If an external response is lost, a blind retry is unsafe: first establish whether the original operation completed.
After a restart and replay of stored events, the number of MAX operations for the tested accounts did not change. Restoring read-receipt history did not create new messages either. This verifies a particular replay scenario; sustained operation needs a separate assessment.
Keep the live pilot separate from large-media tests
The Bitrix24 route verified text, PDFs, source-account routing and delivery events. Photos, audio, video, edits, deletions and the first outbound message to a new contact were outside its live acceptance test. A technical gateway for regular MAX accounts was used; compatibility and support must be assessed before deployment.
A different isolated environment with a simulated external channel tested media up to 50 MiB and Chatwoot players. Those results do not establish real MAX behaviour or verify the same files in Bitrix24. Automatic startup after a server reboot and a production SLA also require separate agreement.
Quick checklist
- Choose an agreed pair of test accounts
- Verify the account identity of each conversation
- Send a reply from the normal CRM interface
- Download the PDF at the destination and compare SHA-256
- Check recovery for additional sends
- Accept media, team permissions and operating conditions separately
Links and source code
This article covers: MAX in Bitrix24, Open Channels, MAX integration, PDF acceptance testing.