Building an event website on 1C-Bitrix means constructing a transactional system: registration, ticket sales, QR-code generation, personal account, integration with CRM and payment gateways. A mistake at the start—like storing speakers, schedule, and tickets in a single infoblock—leads to painful data migration six months later when a second event is launched. We solve these problems using proven architecture from over 40 event projects.
What minimal infoblocks do you need?
An event site requires at least four infoblocks. You could get by with three by gluing the schedule to events, but as soon as you run multi-day conferences with parallel tracks, that approach breaks.
Events infoblock (type events) — the main entity. Properties: DATE_START, DATE_END (type 'Date/Time', must be indexed on b_iblock_element_property), VENUE (link to a Highload-block of venues), CAPACITY (checked in OnSaleOrderBeforeSaved), STATUS (list of states), STREAM_URL (accessible after payment), SCHEMA_ORG (computed field for JSON-LD).
Speakers infoblock — separate, with multiple binding to events. Contains photo, bio, company, position, and social links.
Schedule infoblock — each element is a time slot linked to an event and speaker, with type (talk, workshop, break).
Tickets infoblock — products of the e‑commerce catalog. Each ticket type is a separate element with properties EVENT_ID, TICKET_TYPE, AVAILABLE_SEATS, VALID_UNTIL.
Why not Highload-blocks? For speakers and schedule the data volume is small, and infoblocks provide ready-made components and a visual editor. Highload is justified for venues (500+ records) and check-in logs.
How to organize ticket sales on Bitrix?
This is the central and hardest part. A ticket is a product in the catalog, but with non-standard logic: linked to a date, personalized, quantity-limited.
Product = element of the 'Tickets' infoblock connected to the e‑commerce catalog. Each ticket type for each event is a separate product. A 500-person conference with three ticket types means three products, each with its own warehouse stock.
Warehouse accounting automatically decreases stock when an item is added to the cart. When stock reaches zero, the 'Buy' button is replaced with 'Sold out' — checked via CCatalogProduct::GetByID() in the template.
The order process includes a custom step with participant fields, payment via YooKassa, Stripe, or PayPal, and the OnSalePaymentEntitySaved event that generates a QR code and sends an email. Promo codes are implemented through catalog.discount with a promo-code condition.
The handler OnSaleOrderBeforeSaved rejects the order if there are no seats. Additional reservation: decreasing QUANTITY on adding to cart with a 30-minute release via an agent. 1С-Битрикс agents in this case free the reservation. This prevents double sales under high load.
Personal account and notifications
For free events — a custom component that writes to a Highload-block and creates a lead in CRM via REST API. For paid ones — automatic registration upon payment.
Member personal account based on sale.personal.section with a custom template: list of events, order history, download PDF ticket with QR, access to stream (link appears 30 minutes before start), participant certificate.
Countdown timer — JS using setInterval with server time. Stream component with access check: authentication, paid ticket, time. On mismatch — redirect to purchase.
Email notifications via the 'subscribe' module: registration confirmation, ticket after payment (with PDF), 24-hour reminder (agent), schedule change (handler OnAfterIBlockElementUpdate).
SEO and calendar
Schema.org Event — in result_modifier.php we generate JSON-LD markup with fields name, startDate, location, offers, performer. The availability field dynamically switches between InStock and SoldOut.
Event calendar: custom component + FullCalendar.js — interactive, cached, loads 3 times faster than the standard one with 50 events. For simple lists the standard iblock.element.list suffices.
What stages does event website development include?
The process is divided into seven stages: planning (1–2 weeks), design (1–2), backend (2–4), frontend (2–3), integrations (1–2), testing (1–2), launch (3–5 days). Approximate timelines depend on scale:
| Project scale | Approximate timeline |
|---|---|
| Single event, registration without payment | 3–5 weeks |
| Event with ticket sales and QR | 6–9 weeks |
| Multi-event platform with personal account | 8–12 weeks |
What's included in the work
| Phase | Outcome |
|---|---|
| Requirements analysis | Technical specification, prototype |
| Architecture design | Infoblock scheme, HL-blocks, agents |
| Component development | Backend logic, templates, API |
| Integrations | Payment systems, CRM, 1C, CDEK |
| QR generation | endroid/qr-code library |
| Check-in | Entry via QR, verification |
| Testing | Load test (simulating 500 purchases) |
| Documentation and training | Admin guide |
| Warranty support | 1 month after launch |
Automating ticket sales pays off after just two events by reducing manual work. Get a consultation on your event site architecture — our engineers will select the optimal infoblock structure and integrations. Contact us to discuss your project.