Запрошення користувачів за email та посиланням — готова реалізація
Запрошення користувачів — типовий біль B2B
У закритих B2B-продуктах критичний контроль доступу: новий користувач має потрапити лише у свою організацію, і одразу з правильною роллю. Ми реалізували десятки таких flow — від простих посилань до складних воркфлоу з підтвердженнями. Ключове — правильна обробка edge cases: дублі, прострочені посилання, зміна email. Часто зустрічаємо ситуацію, коли запрошення надіслано на корпоративний email, а користувач уже зареєстрований з особистим — потрібне злиття акаунтів. Або коли адміністратор хоче відкликати запрошення після відправки. Наш досвід (понад 5 років і 40+ проєктів із впровадження аутентифікації) показує, що стандартна реалізація без урахування цих нюансів призводить до багів і скарг клієнтів.
Як реалізувати безпечне запрошення користувачів за email?
Основний підхід — генерація унікального токена, який зберігається в БД і має термін дії. У нашому стеку ми використовуємо Prisma ORM для схеми даних і Next.js Server Actions для серверної логіки. Базова модель запрошення включає email, роль, токен, статус і дату закінчення. Статуси — PENDING, ACCEPTED, EXPIRED, REVOKED — перемикаються автоматично або вручну адміністратором.
| Статус | Опис |
|---|---|
| PENDING | Запрошення надіслано, очікує прийняття |
| ACCEPTED | Користувач прийняв запрошення і доданий в організацію |
| EXPIRED | Термін дії закінчився (за замовчуванням 7 днів) |
| REVOKED | Відкликано адміністратором до прийняття |
Токен генерується як випадковий рядок за допомогою crypto.randomUUID() і хешується перед збереженням. При прийнятті перевіряється не лише наявність, але й статус «PENDING», а також термін дії. Якщо токен прострочений, запрошення автоматично позначається «EXPIRED». Для захисту від повторного використання після прийняття токен видаляється або переводиться в «ACCEPTED».
Типові проблеми при реалізації запрошень
- Дублікати у випадку, коли користувач надсилає кілька запрошень на один email. Система або ігнорує, або оновлює попереднє. Ми використовуємо unique constraint на email у межах організації.
- Зміна email при прийнятті запрошення: користувач може прийняти запрошення на інший email — потрібна верифікація. У нашому flow ми вимагаємо підтвердження нового email перед прийняттям.
- Закінчення посилання: час життя за замовчуванням 7 днів, але можна налаштувати під вимоги клієнта. Після закінчення показуємо сторінку з пропозицією запросити нове запрошення.
- Рольова модель: при створенні запрошення вказується роль (OWNER, ADMIN, MEMBER, VIEWER). Після прийняття користувач додається в організацію з цією роллю. Адміністратор може змінити роль уже після прийняття.
Чому запрошення кращі за відкриту реєстрацію?
Open registration у B2B породжує хаос: хто завгодно може зареєструватися, доводиться вручну призначати організації. Запрошення за посиланням дає безпеку та автоматизацію: користувач отримує роль одразу, організація фіксується, адміністратор бачить історію. Такий підхід знижує навантаження на підтримку в 2–3 рази. Порівняно з відкритою реєстрацією, запрошення за посиланням у 2–3 рази ефективніше для B2B-продуктів.
Порівняння способів реєстрації
Вибір між відкритою реєстрацією та запрошенням залежить від вимог. Відкрита реєстрація простіша для користувача, але потребує адміністративної роботи з призначення організацій та ролей. Запрошення за email з підтвердженням — надійний, але багатокроковий процес. Запрошення за посиланням — золота середина: безпечно, автоматизовано, зручно для адміна та користувача. У нашому досвіді компанії, які перейшли з відкритої реєстрації на запрошення, скорочують час онбордингу нового співробітника на 70%.
Що входить у роботу
- Аналіз рольової моделі та схеми даних.
- Проєктування та реалізація моделі Invitation у Prisma.
- Розробка Server Actions для відправки та прийняття запрошень.
- Створення email-шаблонів у React Email з підтримкою брендингу.
- Інтеграція з поштовим сервісом (Resend/SendGrid) та налаштування webhook’ів.
- Сторінка прийняття запрошення з обробкою edge cases (прострочений токен, повторне використання).
- Unit-тести (перевірка статусів, валідація) та інтеграційні тести повного flow.
- Документація по API та інструкції для адміністратора.
- Підтримка протягом 30 днів після деплою.
Процес роботи: від задачі до деплою
- Аналітика — визначаємо ролі, схему даних, вимоги до безпеки. Збираємо сценарії використання та edge cases.
- Проєктування — модель Invitation у Prisma, вибір стеку (Next.js, React Email, Resend). Проєктуємо API endpoints через Server Actions.
- Реалізація — пишемо Server Actions для відправки та прийняття запрошень, створюємо email-шаблони в React Email, розробляємо сторінку з токеном для прийняття.
- Тестування — unit-тести на валідацію (наприклад, перевірка статусу, терміну), інтеграційні тести на повний flow (відправка до прийняття).
- Деплой — налаштовуємо змінні оточення (ключі Resend/SendGrid, база даних), моніторинг доставки листів через webhook’и.
Наш досвід та гарантії
Ми реалізували подібні системи для 15+ B2B-продуктів на Next.js та Laravel. Гарантуємо стабільну роботу, відповідність Core Web Vitals та документацію flow. Досвід інтеграції з поштовими сервісами забезпечує доставку листів без спам-фільтрів. Ми також надаємо гарантію на реалізований код протягом 30 днів після деплою.
Терміни та вартість
Реалізація типового invitation flow з email та обробкою edge cases займає від 3 до 5 робочих днів. Типова вартість реалізації розраховується індивідуально в залежності від складності рольової моделі, необхідності інтеграції із зовнішніми сервісами та додаткових вимог.
Як почати?
Зв'яжіться з нами — ми оцінимо ваш проєкт і запропонуємо оптимальне рішення. Замовте реалізацію запрошувальної системи під ключ. Отримайте готову систему з тестами та документацією.