Integration of 1C-Bitrix with HelpDeskEddy

Integration of 1C-Bitrix with HelpDeskEddy

Customer placed order in Bitrix e-shop, wrote support via site widget, then clarified by email, then called. Without integration operator sees three unlinked tickets in HelpDeskEddy and doesn't know it's one person with one order. Integration links HelpDeskEddy tickets to Bitrix orders and customers — operator opens ticket and immediately sees purchase history.

Interaction architecture

HelpDeskEddy provides REST API (https://{domain}.helpdeskeddy.com/api/v1/). Authorization — API key in Authorization: Bearer {token} header. Main entities: tickets (tickets), users (users), messages (messages), custom fields (custom_fields).

Bitrix provides order data via sale module and user data via main module. Integration builds on two data streams:

1. Bitrix → HelpDeskEddy: on order creation or user registration data sent to HelpDeskEddy to enrich customer profile.
2. HelpDeskEddy → Bitrix: on ticket creation or update webhook notifies Bitrix and ticket data displays in admin panel or personal account.

User synchronization

On user registration in Bitrix (event OnAfterUserRegister) handler creates or updates contact in HelpDeskEddy via POST /api/v1/users. Link key — email. Additionally send: name, phone, Bitrix user ID (in HelpDeskEddy custom field).

Reverse sync: when ticket created from unknown email HelpDeskEddy sends webhook. Handler in Bitrix checks if user with that email exists in b_user. If yes — links. If no — creates minimal profile or leaves as anonymous inquiry.

Mapping storage: table custom_hde_user_map (or UF-field UF_HDE_USER_ID in b_user table) links Bitrix user ID to HelpDeskEddy contact ID. Needed for fast lookup without API call on each action.

Passing order data to ticket

When operator opens ticket in HelpDeskEddy they need order data. Two approaches:

Approach 1: Push on order creation. Event handler OnSaleOrderSaved from sale module sends order data to HelpDeskEddy — number, sum, status, product list — to contact custom fields or as internal note. Advantage: data available offline. Disadvantage: order status change requires updating HelpDeskEddy data.

Approach 2: Pull on request. Widget configured in HelpDeskEddy (iframe) loads data from Bitrix by API. Operator clicks button — widget requests /api/orders/?user_id=123 on Bitrix side and shows order list. Advantage: data always current. Disadvantage: requires API endpoint on Bitrix side.

Recommended strategy — combined: push main data (number, sum, status) + pull for details (order composition, status history).

Feedback widget on site

HelpDeskEddy provides JavaScript widget for embedding on site. Widget code added to Bitrix site template (file footer.php or via \Bitrix\Main\Page\Asset::getInstance()->addString()).

For personalization pass authorized user data to widget:

window.HDE_CONFIG = {
    user_email: '<?= $USER->GetEmail() ?>',
    user_name: '<?= $USER->GetFullName() ?>',
    custom_fields: {
        bitrix_user_id: '<?= $USER->GetID() ?>'
    }
};

This saves customer from re-entering email and links ticket to profile automatically.

Displaying tickets in personal account

In Bitrix personal account (/personal/) add "My Requests" section. Custom component requests tickets via GET /api/v1/tickets?user_id={hde_user_id} and outputs list: ticket number, subject, status, last reply date. Click on ticket opens conversation.

Cache ticket list for 60 seconds — HelpDeskEddy API has rate limit (usually 60 requests per minute) and active personal account easily exceeds it.

Webhooks and event processing

HelpDeskEddy sends webhooks on events: ticket creation, new message, status change. Configuration — in HelpDeskEddy admin, "Integrations → Webhooks".

On Bitrix side create handler /api/hde-webhook.php that:

1. Verifies request signature (HMAC-SHA256 with secret key).
2. Parses JSON body.
3. By event type executes action: updates order UF-field, sends email to manager, creates CRM task.

Timeline