Outlook Calendar — стандарт у корпоративному середовищі. Коли клієнт бронює послугу на сайті, менеджеру доводиться вручну переносити зустріч у календар. Це забирає час, веде до помилок і задвоєнь. За даними Microsoft, ручне керування зустрічами займає до 30% робочого часу адміністратора. Ми вирішуємо цю проблему: реалізуємо двосторонню синхронізацію бронювань із Microsoft Outlook Calendar через Microsoft Graph API. Все працює автоматично — без ручного введення. За 3–5 робочих днів ви отримуєте інтеграцію «під ключ», яка скорочує кількість помилок на 90% і економить 20+ годин на місяць.
Як працює двостороння синхронізація з Outlook Calendar?
Синхронізація побудована на подіях та вебхуках. Коли користувач бронює час на сайті, наш сервер створює подію в календарі співробітника через Microsoft Graph API. При зміні або скасуванні бронювання подія оновлюється або видаляється. Зворотній зв'язок реалізований через вебхуки: якщо співробітник змінив подію в Outlook, ми отримуємо сповіщення та оновлюємо запис у базі. Все — із затримкою не більше хвилини.
Авторизація через Microsoft Identity Platform
Для доступу до календаря використовуємо OAuth2 flow з Azure AD. Реєструємо додаток в Azure Portal, запитуємо scope Calendars.ReadWrite та offline_access для refresh токена. Код авторизації виглядає так:
Route::get('/integrations/outlook/connect', function () { $url = 'https://login.microsoftonline.com/common/oauth2/v2.0/authorize?' . http_build_query([ 'client_id' => config('services.microsoft.client_id'), 'scope' => 'Calendars.ReadWrite offline_access', 'redirect_uri' => route('integrations.outlook.callback'), 'response_type' => 'code', ]); return redirect($url); }); Після отримання токена створюємо подію через Microsoft Graph API:
use Microsoft\Graph\Graph; use Microsoft\Graph\Model\Event as GraphEvent; class OutlookCalendarService { private Graph $graph; public function __construct(string $accessToken) { $this->graph = new Graph(); $this->graph->setAccessToken($accessToken); } public function createEvent(Booking $booking): string { $event = new GraphEvent(); $event->setSubject("{$booking->service->name} — {$booking->customer_name}"); $event->setBody([ 'contentType' => 'HTML', 'content' => $this->buildHtmlBody($booking), ]); $event->setStart([ 'dateTime' => $booking->starts_at->toIso8601String(), 'timeZone' => 'Russian Standard Time', ]); $event->setEnd([ 'dateTime' => $booking->ends_at->toIso8601String(), 'timeZone' => 'Russian Standard Time', ]); $created = $this->graph ->createRequest('POST', '/me/events') ->attachBody($event) ->setReturnType(GraphEvent::class) ->execute(); return $created->getId(); } } Чому Outlook Calendar — стандарт для B2B-сервісів?
Outlook використовується в 80% великих компаній. Синхронізація з ним дає переваги: співробітники бачать бронювання одразу в календарі, не відкриваючи сторонні системи. Знижується ризик подвійних записів — помилки ручного введення зникають. Azure AD забезпечує корпоративний рівень безпеки: доступ лише через авторизовані облікові записи.
Порівняння з Google Calendar:
| Критерій | Outlook (Microsoft Graph) | Google Calendar API |
|---|---|---|
| API | Microsoft Graph REST | Google Calendar API v3 |
| Авторизація | OAuth2 + Azure AD | OAuth2 + Google Identity |
| Часові зони | Імена Windows (Russian Standard Time) | IANA (Europe/Moscow) |
| Вебхуки | Підписки з валідаційним challenge | Push-повідомлення через канали |
| Вимоги до токена | Refresh token для фону | Refresh token для фону |
Outlook зручніший для B2B через вбудовану інтеграцію з Microsoft 365 та суворі політики безпеки.
Які технічні складнощі виникають при інтеграції?
Найчастіші проблеми: неправильний формат часової зони, пропуск валідаційного challenge для вебхуків та завершення access token. Розберемо кожну.
Часові зони. Outlook використовує Windows-імена (наприклад, Russian Standard Time), а не IANA. Якщо передати Europe/Moscow, подія створиться з помилкою. Наш сервіс перетворює IANA на Windows-імена через попередньо встановлений мапінг.
Валідаційний challenge. При створенні підписки Microsoft надсилає GET-запит з validationToken. Треба повернути цей токен у тілі відповіді протягом 10 секунд. Ми реалізуємо endpoint, який обробляє це автоматично.
Завершення токена. Access token живе 60–90 хвилин. Використовуємо refresh token для автоматичного оновлення. Зберігаємо refresh токен у зашифрованому вигляді та запускаємо cron-завдання для його оновлення раз на годину.
Що входить в роботу з інтеграції
Ми надаємо повний обсяг «під ключ»:
- Аудит вашої системи бронювань — структура даних, логіка скасувань/переносів.
- Реєстрація додатка в Azure Portal та налаштування дозволів.
- Розробка модуля двосторонньої синхронізації (створення, оновлення, видалення подій).
- Налаштування вебхуків для миттєвого оновлення при змінах в Outlook.
- Тестування на різних сценаріях (одночасні бронювання, відмови, зміна часу).
- Надання документації та навчання адміністратора.
- Гарантійна підтримка 30 днів після запуску.
Додатково можемо налаштувати сповіщення про події (email, SMS) або інтегрувати з CRM.
Процес роботи та терміни
- Аналітика — вивчаємо бізнес-логіку та поточну реалізацію. (0.5 дня)
- Проектування — узгоджуємо схему даних та сценарії синхронізації. (0.5 дня)
- Розробка — пишемо код інтеграції, налаштовуємо вебхуки. (2–3 дні)
- Тестування — перевіряємо на ваших тестових даних, виправляємо дефекти. (1 день)
- Деплой — розгортаємо на продакшені, фіксуємо доступи. (0.5 дня)
Разом: 3–5 робочих днів залежно від складності. Зв'яжіться з нами для безкоштовної оцінки вашого проекту.
| Порівняння ручного та автоматичного управління | Ручне | Автоматичне |
|---|---|---|
| Час на бронь | 5–10 хвилин | <1 хвилини |
| Помилки | 10–15% | <1% |
| Економія часу на місяць | – | 20+ годин |
Кейс із практики: інтеграція для мережі клінік
Клієнт керував 12 філіями. Бронювання приймалися через сайт, але не потрапляли в Outlook — менеджери перепечатували дані. Після впровадження нашої інтеграції час на обробку скоротився з 8 хвилин до 30 секунд, а кількість подвійних записів впала до нуля. Система обробляє до 1000 бронювань на день без збоїв.
Типові помилки при інтеграції
- Неправильна часова зона. Використовуємо мапінг IANA→Windows.
- Пропуск валідаційного challenge. Автоматично відповідаємо на запит перевірки.
- Завершення access token. Refresh token оновлюється автоматично.
- Відсутність обробки повторних подій. Якщо вебхук прийшов повторно, ідемпотентність гарантується через унікальний ID підписки.
Наші інженери мають 5+ років досвіду з Microsoft Graph API. Гарантуємо стабільну роботу синхронізації 24/7. Отримайте консультацію — ми відповімо на питання та підготуємо комерційну пропозицію. Залиште заявку, і ми зв'яжемося з вами протягом дня.