Integration of 1C-Bitrix with online recording services (Dikidi)

Integration of 1C-Bitrix with Dikidi Online Booking Services

A beauty salon or clinic manages bookings in Dikidi — clients reserve through the app, masters see their schedules. The Bitrix site lives separately: service catalog, prices, promotions, but booking is only by phone or through a Dikidi widget. Integration is needed so the site and booking system work as a whole: current schedule on site, booking without redirecting to external service, client data goes to CRM.

Dikidi API: what's available

Dikidi provides a REST API for partners (documentation available upon request through support). Main endpoints:

• GET /api/v2/company/{id}/services — list of services with prices and duration
• GET /api/v2/company/{id}/masters — masters with schedules
• GET /api/v2/company/{id}/schedule — available slots for a date for a specific master and service
• POST /api/v2/company/{id}/booking — create booking (master, service, date, time, client data)
• GET /api/v2/company/{id}/booking/{id} — booking status

Authorization — by API key in the Authorization header. The key is issued when signing up for a plan with API access.

Limitation: not all Dikidi plans include API. On the basic plan, only the widget (iframe) is available. API is on "Business" and higher plans. Clarify before starting.

Option 1: Dikidi widget (simple)

Dikidi provides an iframe widget for embedding on the site. Insertion code — one line in a component template or page editor:

<iframe src="https://dikidi.net/widget/{company_id}" width="100%" height="700"></iframe>

Pros: works in 10 minutes, requires no development. Cons: external design inside your site, no UX control, booking data doesn't go to Bitrix, zero SEO value.

Option 2: custom integration via API

Full integration where the booking form is part of the Bitrix site, and Dikidi acts as the schedule backend.

Architecture:

1. Caching services and masters. Daily cron script (CAgent) queries the Dikidi API for services and masters and saves them in highload block or infoblock. This way catalog pages work without API requests to Dikidi on every hit.

2. Booking form component. Custom component custom:dikidi.booking on the service page:

   • Step 1: choose master (data from HL block)
   • Step 2: choose date and time — AJAX request to Dikidi API /schedule (real time, cannot cache slots — they change every minute)
   • Step 3: client contact data
   • Step 4: confirmation — POST /booking

3. Response handling. On successful booking, Dikidi returns booking_id. Save to DikidiBooking HL block with link to Bitrix user (if authorized) and CRM record.

Synchronization with Bitrix24 CRM

Booking through site should create a lead or deal in CRM:

• On booking confirmation — REST request crm.lead.add or crm.deal.add with data: client name, phone, service, master, date/time
• Lead source — "Site booking (Dikidi)" (add to sources reference through crm.status.add)
• In deal UF field save Dikidi booking_id for cross-linking

Reverse synchronization: if manager cancels deal in CRM — webhook calls DELETE /booking/{id} on Dikidi API. Implemented via CRM robot on "Cancelled" stage.

Webhook from Dikidi

Dikidi supports outgoing notifications about events (if configured): new booking, cancellation, change. Endpoint on Bitrix side — php script at /local/tools/dikidi_webhook.php, which:

• Verifies request signature
• Creates or updates booking in HL block
• Creates lead in CRM (if booking made through Dikidi app, not through site)

This covers the reverse scenario: client booked through Dikidi app — site and CRM know about it.

Pitfalls

• Time zone. Dikidi stores time in UTC, Bitrix — in server time zone. If not converted — booking at 15:00 shows as 18:00 (for UTC+3).
• API rate limit. Dikidi limits request frequency. If 10 users on site simultaneously choose slots — you can hit the limit. Solution: cache master and service lists, schedule requests only when specific master and date are chosen.
• Client duplicates. One client books through site (created in Dikidi) and through app. Dikidi identifies by phone — no issues. But in Bitrix24 CRM a duplicate can appear if webhook and site handler create two leads. Solution: before creating lead check crm.duplicate.findbycomm.

Implementation Timelines

Dikidi is a closed ecosystem, and integration quality depends on API availability on your plan. Before starting, verify the API key is issued and endpoints respond to test requests.