Restaurant Website Development on 1C-Bitrix

We develop restaurant websites on 1C-Bitrix turnkey: from menu infoblock structure and online table booking to delivery order system, POS synchronization, and integration with Yandex.Eda and Delivery Club aggregators. In our practice — over 50 completed projects, integrations with iiko, r_keeper, and Poster. Our team holds 1C-Bitrix certification and has over 10 years of experience in restaurant site development. We guarantee reliable POS integration and post-launch support.

A restaurant website is a working tool that requires a well-thought architecture: menu infoblocks, REST API of cash systems, custom order processing components, and real-time inventory synchronization. If at the start you don't design the link between the menu infoblock and the POS system, three months later you'll find that the waiter added a new item in iiko, but it's not on the website — because synchronization works one way and nobody wrote a reverse handler.

What is the data structure for the menu infoblock?

Restaurant menu is an infoblock with section categories and element dishes. Sections: Breakfasts, Salads, Hot Dishes, Desserts, Drinks, Wine List. Nesting — one level; for subcategories (e.g., Red Wine inside Wine List) a second level of sections is used.

Dish element properties:

• WEIGHT — numeric, grams. Displayed on the card and in Schema.org markup
• CALORIES — numeric, kcal. Optionally extended block: proteins, fats, carbs (three separate properties PROTEINS, FATS, CARBS)
• ALLERGENS — multiple list: gluten, lactose, nuts, seafood, eggs, soy. Filter by allergens via CIBlockElement::GetList() with PROPERTY_ALLERGENS in filter
• PRICE — numeric. Not through catalog module if no cart needed — regular infoblock property. If online payment needed — connection to trade catalog via CCatalog::Add()
• PHOTO — file. Main dish photo. Additional photos — multiple property MORE_PHOTOS
• IS_NEW — checkbox. New mark for highlighting in list
• IS_SPICY — checkbox. Spicy dish mark
• STOP_LIST — checkbox. Dish temporarily unavailable (ingredient out). Element not deleted, hidden by filter in component template
• SORT_ORDER — numeric. Order within section allows chef to place signature dishes first via admin panel

For restaurants with seasonal menus, add property SEASON (multiple list: spring, summer, autumn, winter) and filter by current season in component.php.

How does online ordering and POS integration work?

This is technically the most loaded part of the project. The restaurant works with a cash system — iiko, r_keeper, or Poster. The website must not just accept orders but transfer them to the cash register in real time and receive feedback: confirmation, preparation time, status.

Interaction architecture with iiko:

iiko provides iiko Transport API (formerly iiko Biz API). Authorization by apiLogin, token retrieval via POST /api/1/access_token. Token lives 60 minutes, cached in $_SESSION or a Highload-block with TTL. According to iiko API docsiiko API, creating an order uses POST /api/1/deliveries/create. Request body contains:

{
  "organizationId": "...",
  "order": {
    "phone": "+375...",
    "orderTypeId": "...",
    "items": [
      {
        "productId": "iiko-product-uuid",
        "amount": 2,
        "modifiers": [...]
      }
    ],
    "address": {
      "street": "...",
      "house": "...",
      "flat": "..."
    },
    "comment": "No onions"
  }
}

Critical point — mapping productId. In the Bitrix infoblock each dish stores property IIKO_PRODUCT_ID (string, UUID from iiko). When syncing the menu via GET /api/1/nomenclature, the full iiko catalog is loaded and matched with infoblock elements by this UUID. Synchronization runs by CAgent agent every 15 minutes or via webhook from iiko.

Synced from iiko to Bitrix:

• Dish availability (stop-list). iiko sends POST to webhook endpoint /api/iiko-stoplist/. Handler updates STOP_LIST property of the corresponding infoblock element via CIBlockElement::SetPropertyValuesEx()
• Price. If the restaurant changes prices in the cash register, they must arrive on the site. Handler in agent compares prices from /api/1/nomenclature with PRICE in infoblock and updates differences
• Modifiers (add-ons, sides). Stored in a separate infoblock Modifiers with property IIKO_MODIFIER_ID

Sent from site to iiko:

• Order with items, address, comment
• Payment type (online or on delivery)
• Promocode, if any — discount calculated on iiko side

Integration with r_keeper:

r_keeper uses UCS DeliveryPOS API. The principle is similar, but protocol is XML-RPC instead of JSON REST. Requests are wrapped in XML envelope, responses parsed via SimpleXMLElement. Product mapping by MenuItemID. Main complexity — r_keeper requires a VPN tunnel to the restaurant server, while iiko works via cloud.

Integration with Poster POS:

Poster provides REST API with OAuth authorization. Creating order — POST /api/incomingOrders.createIncomingOrder. Poster is simpler to integrate: JSON API, cloud deployment, webhook for order status updates. Mapping by product_id from Poster.

Order status handling: After creating an order in POS, the site must track its status. Two approaches:

1. Polling — agent or cron task every 60 seconds queries the POS API by orderId. Statuses: Accepted, Preparing, En route, Delivered. Updates STATUS property in Highload-block Orders
2. Webhook — POS sends POST to /api/order-status/ on status change. Preferred for iiko and Poster, but not always available for r_keeper

Status is displayed to client on page /my-orders/ via AJAX polling every 30 seconds or via WebSocket (if infrastructure allows).

Table Reservation

Custom component project:table.reservation with form: date, time, number of guests, name, phone, comment.

Reservation logic:

• Data written to Highload-block Reservations: DATE, TIME, GUESTS, NAME, PHONE, STATUS, TABLE_ID
• Tables — separate Highload-block: TABLE_NUMBER, CAPACITY, ZONE (hall, terrace, VIP)
• On reservation, component checks availability: query from Reservations by DATE + TIME with +-2 hour window, match with capacity of free tables
• If no free tables, offer nearest available time

Integration with Bitrix24 CRM: Each reservation creates a lead via CRest::call('crm.lead.add', [...]). Parameters:

$leadData = [
    'TITLE' => 'Table reservation: ' . $date . ' ' . $time,
    'NAME' => $name,
    'PHONE' => [['VALUE' => $phone, 'VALUE_TYPE' => 'WORK']],
    'SOURCE_ID' => 'WEB',
    'UF_CRM_TABLE' => $tableNumber,
    'UF_CRM_GUESTS' => $guests,
    'COMMENTS' => $comment
];
CRest::call('crm.lead.add', ['fields' => $leadData]);

Hostess sees reservations in CRM and confirms them. Lead status Confirmed → handler updates STATUS in Highload-block → customer receives SMS via messageservice module or external SMS gateway.

Frontend Optimization

Photo Gallery and Image Optimization

Food photography — heavy files. Originals from photographer — 5-10 MB per shot. Site needs three sizes: thumbnail for menu list (400x300), medium for dish card (800x600), full-size for lightbox (1600x1200).

Resize via CFile::ResizeImageGet() with BX_RESIZE_IMAGE_PROPORTIONAL. Result cached in /upload/resize_cache/. For WebP — conversion via imagewebp() in OnBeforeFileResize handler or via Nginx module ngx_http_image_filter_module.

srcset for Retina displays:

<img
  src="/upload/resize_cache/menu/800x600/dish.webp"
  srcset="/upload/resize_cache/menu/400x300/dish.webp 400w,
          /upload/resize_cache/menu/800x600/dish.webp 800w,
          /upload/resize_cache/menu/1600x1200/dish.webp 1600w"
  sizes="(max-width: 640px) 400px, (max-width: 1024px) 800px, 1600px"
  loading="lazy"
  alt="1C-Bitrix restaurant website with POS integration and online ordering"
>

Attribute loading="lazy" — native lazy loading. For older browsers — IntersectionObserver in JS. On a menu page with 50+ dishes, this saves 30-40 MB of initial load.

Mobile-first: 80% Traffic from Phones

Restaurant website is searched from phone — restaurant nearby, delivery menu. Template built mobile-first:

• Menu categories — horizontal scroll with overflow-x: auto, not a dropdown
• Dish card — full-width photo, name, weight, price. Add button fixed at bottom via position: sticky
• Order form — minimal fields. Phone + address. Name and comment optional. Address autofill via Dadata API (POST https://suggestions.dadata.ru/suggestions/api/4_1/rs/suggest/address)
• Reservation form — native and instead of custom datepickers

Responsiveness — CSS Grid + Flexbox in component template. Three breakpoints: 375px (phone), 768px (tablet), 1280px (desktop). Testing via Lighthouse: target Performance > 90, LCP < 2.5s. Average conversion rate for online ordering is 5% on mobile.

SEO and Multilingual Features

Multilingual Menu

For restaurants in tourist areas — menu in multiple languages. In 1C-Bitrix multilingualism is implemented via:

• Separate site in multisite system (LID = s1 for Russian, s2 for English). Infoblocks attached to both sites, properties NAME_EN, DESCRIPTION_EN — additional text properties
• Or via property LANGUAGE (list: ru, en, de) and filtering in component by current language LANGUAGE_ID

First option is more reliable: different URLs (/menu/ and /en/menu/), correct hreflang tags, independent SEO settings.

Schema.org: Restaurant + Menu

In result_modifier.php JSON-LD markup is formed:

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Restaurant Name",
  "servesCuisine": "Italian",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "...",
    "addressLocality": "Minsk"
  },
  "openingHoursSpecification": [...],
  "menu": {
    "@type": "Menu",
    "hasMenuSection": [
      {
        "@type": "MenuSection",
        "name": "Hot Dishes",
        "hasMenuItem": [
          {
            "@type": "MenuItem",
            "name": "Ribeye steak",
            "description": "...",
            "nutrition": {
              "@type": "NutritionInformation",
              "calories": "850 cal"
            },
            "offers": {
              "@type": "Offer",
              "priceCurrency": "BYN"
            }
          }
        ]
      }
    ]
  }
}

Markup output via $APPLICATION->AddHeadString(). Types Restaurant, Menu, MenuItem — separate Schema.org entities, Google recognizes them for Rich Snippets in search results.

Marketing Features

Promotions and Special Offers

Infoblock Promotions (type promotions). Properties: DATE_START, DATE_END, PROMO_TYPE (business lunch, happy hour, seasonal), DISCOUNT_PERCENT, LINKED_DISHES (multiple binding to items of menu infoblock).

Display on main page via news.list with date filter: >=DATE_START and <=DATE_END relative to current date. Expired promotions automatically hidden without admin intervention.

For business lunch — separate menu section with time constraint: component checks server time and shows Business Lunch block only from 12:00 to 16:00.

Restaurant Events

Infoblock Events — for announcements: live music, themed evenings, tastings. Properties: EVENT_DATE, EVENT_TIME, DESCRIPTION, COVER_CHARGE (checkbox — paid/free entry), POSTER (image).

Display — feed on main page (three nearest events) and separate page /events/ with list. Past events moved to archive automatically by EVENT_DATE < now().

Integration with Delivery Aggregators

Yandex.Eda and Delivery Club provide API for partner restaurants. Integration is bidirectional:

• Menu export — generating XML/JSON feed with items, prices, photos, stop-list. Feed generated by agent every 30 minutes from menu infoblock
• Order reception — webhook from aggregator to /api/aggregator-order/. Handler creates order in Highload-block and passes to POS system

This saves the administrator from manually updating menus in aggregator accounts, reducing manual work by about 10 hours per week, equating to roughly $1,000 monthly savings.

Deliverables and Support

• Documentation: Detailed infoblock structure, API integration scheme, deployment checklist.
• Admin training: One 2‑hour video call session covering menu management, order processing, and troubleshooting.
• Post‑launch support: 1 month of bug fixes and minor adjustments (up to 5 hours).
• Access: Full access to Bitrix admin panel, source code repository, and POS integration credentials.

Typical setup fee for POS integration: $2,500. Average total project cost: $9,000.

Development Stages

1. Discovery (1-2 weeks) — infoblock structure, POS integration scheme, page prototypes, data mapping between Bitrix and cash system
2. Design (1-2 weeks) — mockups: main page, menu (list + card), reservation, delivery, promotions
3. Backend (2-4 weeks) — infoblocks, menu and reservation components, POS integration, CRM, order processing
4. Frontend (1-3 weeks) — responsive templates, image optimization, order and reservation forms, AJAX status updates
5. Integrations (1-2 weeks) — POS system, delivery aggregators, SMS notifications, payment system
6. Testing (1-2 weeks) — functional, test orders via POS, mobile testing, load testing
7. Launch (3-5 days) — deploy, monitor cash sync, verify with real orders

Development costs vary; a typical project starts at $3,500 for a basic menu+reservation site and can exceed $15,000 for a full system with all integrations.

Clients typically see a 30% increase in online orders within 3 months and average ticket size grows by 25%.

Timelines depend on chosen POS system (iiko integrates faster than r_keeper due to cloud API), number of languages, and client account requirements. On average, iiko integration takes 2-3 weeks, r_keeper 3-4 weeks, and Poster 1-2 weeks.

How to properly design infoblocks?

When developing a 1C-Bitrix website, we see dozens of projects where poor infoblock structure slows down the site. Typical scenario: the client asks for a "product catalog." The developer creates one infoblock catalog, puts 15 properties in it. Six months later – 40 properties, 8 of which are used only for one category. The filter lags, the b_iblock_element_property table grows to millions of rows, CIBlockElement::GetList runs for 3 seconds. Consequences – conversion drop, loss of customers, additional optimization costs. In one project after catalog refactoring, page generation time dropped from 4.2 to 0.8 seconds, and annual support costs were reduced by over $10,000 through eliminated redundant queries and agents.

Our approach: design infoblocks before writing a single line of code. Separate infoblocks for entities (products, categories, brands), dictionary properties via highload blocks, trade offers for SKUs. This builds performance for years. If you want a preliminary audit of your infoblock schema, contact us for a free review of common mistakes and recommendations.

Why 1C-Bitrix outperforms most CMS for business

The choice of CMS is dictated by business needs, not preferences. Native 1C exchange via catalog.import.1c provides two-way synchronization of products, prices, balances, and orders through CommerceML without third-party modules — five times faster than developing custom exchange on OpenCart or WordPress, saving hundreds of thousands of rubles. Proactive security module includes WAF, file integrity control, SQL injection protection, and two-factor authentication; it's certified for FSTEK requirements. Modular architecture lets you enable only needed modules — iblock, catalog, sale, search — reducing DB queries per hit. Regular patches close vulnerabilities faster than open-source projects (average CVE fix time two weeks). Official documentation is maintained on the vendor's site.

What highload blocks are and how they speed up the catalog

Highload blocks are an alternative to extended infoblock properties when the list of values can grow to thousands of entries. Typical example: manufacturers, countries, colors. If stored as list properties in an infoblock, each filter triggers a full scan of b_iblock_property_enum table. With HL-blocks, selection uses indexes – filter response time drops from 1–2 seconds to 50 ms. We use HLB component and custom queries via Bitrix\Highloadblock\DataManager. This is critical for catalogs with 100,000+ items.

From our practice: an online store with 500,000 items. Standard filter by brand took 4 seconds. The server couldn't handle 50 concurrent requests – pages crashed. We moved the brand directory to an HL-block, added tagged caching for 15 minutes, and set up an agent to clear cache on change. After optimization, filter time was 120 ms, average LCP was 1.8 seconds. The project runs stable without failures.

What integrations are critical for 1C-Bitrix stores

Each e‑commerce project requires reliable connections with payments, fiscalization, logistics, and CRM. We integrate YooKassa, CloudPayments, Tinkoff, Apple Pay, Google Pay for payments; ATOL and OrangeData for 54-FZ compliance via sale.cashbox; CDEK, Boxberry, PEC, Russian Post, Yandex.Delivery for logistics; Bitrix24, amoCRM, Roistat, Calltouch, Mindbox for analytics and CRM. All integrations are configured with proper error handling and fallback logic.

What's included in 1C-Bitrix website development

Each project includes a full set of documentation and artifacts to prevent knowledge loss after handover.

• Technical specification – user stories, infoblock diagrams, integration schemas.
• Source code in Git – with commit history, release tags, branching rules.
• Administrative documentation – description of custom components, deployment instructions, list of agents and events.
• Staff training – up to a 3-hour webinar: admin panel, order management, price settings. Recorded for later review.
• Access to staging during development – test before production deployment.
• Warranty support – bug fixes for 30 days after launch. Post-warranty support packages with SLA (response 2 hours, resolution 8 hours).

Our process and technologies

Tech stack: mobile-first markup, tested on physical devices (iPhone, iPad, Android). Use BrowserStack for Safari on iOS. Performance goals: LCP < 2.5 s, FID < 100 ms, CLS < 0.1. Enable composite site (composite module), CDN, tagged caching, WebP/AVIF, lazy loading. SEO: Schema.org via JSON-LD, auto-generation of sitemap.xml via seo module, canonical and hreflang for multilingual versions. robots.txt blocks /bitrix/ from indexing. CI/CD: Git, auto-deploy via GitLab CI, staging. DB migrations: sprint.migration module with versioning.

Process:

1. Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
2. Design – UI/UX with design system. Components are reusable.
3. Development – write components with custom templates in local/templates/. Business logic in local/modules/.
4. Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
5. Launch – deploy to production, monitoring via UptimeRobot, alerts in Telegram. Fixes for first 48 hours.

Multilingual support and redesign

Full localization via language files lang/ and SITE_ID mechanism. hreflang for each version. Regional versions with different prices and content – IP detection (main.geo) or manual selection. Multidomain – unified management of multiple domains.

Redesign without losing rankings: performance audit (PageSpeed, WebPageTest), SEO (Screaming Frog). New template in local/templates/ with preserved URL structure. 301 redirects only if URL changes significantly. Kernel update, migration to D7 ORM, infoblock restructuring, migration via sprint.migration with Git.

Guarantee and support

We have been working with 1C-Bitrix for 12+ years, completed 500+ projects. Certified developers on staff. Fixed price in contract – no surprises. Warranty period covers code errors. After warranty, subscription packages with SLA (response time 2 hours, resolution 8 hours). 24/7 availability monitoring, alerts in Telegram. Get a consultation and preliminary estimate: contact us via the form on the website or chat – we'll respond within an hour. Order turnkey development – we'll design infoblocks, integrate 1C, and speed up the catalog. If you already have a site on another CMS, order a performance audit and migration to Bitrix.