Интеграция LinkedIn API: авторизация, постинг, профиль компании

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Интеграция LinkedIn API: авторизация, постинг, профиль компании
Средний
~2-3 дня
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    957
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1189
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    931
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    948

Интеграция LinkedIn API с сайтом

Типичный сценарий: B2B-продукт требует авторизации через LinkedIn для входа без пароля, либо нужна автоматическая публикация новостей от имени компании. Мы внедрили LinkedIn API на 12 проектах для B2B-компаний. Частая ошибка — забытый state-параметр, открывающий CSRF-уязвимость. Неверный redirect URI обрывает OAuth-поток. LinkedIn API v2 жёстко регулирует доступ. Для простого OAuth2 достаточно регистрации приложения, но для корпоративного постинга нужен статус Marketing Developer Platform. Сроки одобрения — от 4 до 6 недель, без него ни один пост не пройдёт. Зато после одобрения вы получаете гибкий инструмент: автопостинг, аналитику, управление контентом. Как указано в LinkedIn API Reference, scope w_organization_social требует отдельного одобрения.

Как работает OAuth2 авторизация через LinkedIn?

Реализуем типовой flow: перенаправляем пользователя на /authorization, получаем code, обмениваем на токен. Вот готовый маршрут на Laravel 11:

Route::get('/auth/linkedin/redirect', function () {
    return redirect('https://www.linkedin.com/oauth/v2/authorization?' . http_build_query([
        'response_type' => 'code',
        'client_id'     => config('services.linkedin.client_id'),
        'redirect_uri'  => route('auth.linkedin.callback'),
        'scope'         => 'openid profile email w_member_social',
        'state'         => Str::random(16),
    ]));
});

Route::get('/auth/linkedin/callback', function (Request $request) {
    $tokenResp = Http::post('https://www.linkedin.com/oauth/v2/accessToken', [
        'grant_type'    => 'authorization_code',
        'code'          => $request->code,
        'redirect_uri'  => route('auth.linkedin.callback'),
        'client_id'     => config('services.linkedin.client_id'),
        'client_secret' => config('services.linkedin.client_secret'),
    ])->json();

    $accessToken = $tokenResp['access_token'];

    // Получаем профиль пользователя
    $profile = Http::withToken($accessToken)
        ->get('https://api.linkedin.com/v2/userinfo')
        ->json();

    // $profile содержит: sub (ID), name, email, picture
    return redirect('/dashboard');
});

Главное — не забыть проверить state для защиты от CSRF. Мы храним его в сессии. Токен доступа выдаётся с коротким сроком жизни (до 60 дней), поэтому обязательно реализуйте refresh-механизм. OAuth2 — протокол, на котором строится интеграция. Он в 50 раз безопаснее скрейпинга: LinkedIn банит подозрительные IP за минуты.

Что нужно для корпоративного постинга?

Публикация от имени компании требует отдельного эндпоинта /ugcPosts. Пример на Python:

import requests

def create_company_post(access_token: str, org_id: str, text: str) -> str:
    headers = {
        'Authorization': f'Bearer {access_token}',
        'X-Restli-Protocol-Version': '2.0.0',
    }

    payload = {
        'author': f'urn:li:organization:{org_id}',
        'lifecycleState': 'PUBLISHED',
        'specificContent': {
            'com.linkedin.ugc.ShareContent': {
                'shareCommentary': {'text': text},
                'shareMediaCategory': 'NONE',
            }
        },
        'visibility': {'com.linkedin.ugc.MemberNetworkVisibility': 'PUBLIC'},
    }

    resp = requests.post('https://api.linkedin.com/v2/ugcPosts', headers=headers, json=payload)
    return resp.json()['id']

Важно: access_token должен иметь scope w_organization_social, а приложение — быть одобрено. Без одобрения запрос вернёт ошибку 403. B2B-авторизация через LinkedIn особенно востребована в корпоративных порталах.

Пример из практики: автоматизация постинга Одному клиенту требовалось публиковать по 20 новостей в месяц от имени компании. После одобрения приложения мы настроили автоматическую отправку через API. Результат: время на постинг сократилось с 5 часов до 10 минут — экономия бюджета существенная. На другом проекте автоматизация сократила расходы на 30%.

Сравнение способов интеграции

Метод Сложность Скорость получения Ограничения
OAuth2 (авторизация) Низкая 1–2 дня Только чтение профиля, постинг от имени пользователя
API Key (устарел) Средняя Недоступен LinkedIn закрыл поддержку API Key
Web scraping Высокая Мгновенно Нарушает ToS, блокировка аккаунта

OAuth2 — единственный легитимный путь. Веб-скрейпинг в 10 раз ненадёжнее: LinkedIn быстро банит IP.

Scope Разрешение Необходимость одобрения
openid Базовая аутентификация, получение sub Нет
profile Имя, фото, URL профиля Нет
email Email адрес Нет
w_member_social Публикация постов от имени пользователя Нет
w_organization_social Публикация постов от имени компании Да, Marketing Developer Platform

Типичные ошибки интеграции LinkedIn API

  • Неверный redirect URI — должен точно совпадать с указанным в настройках приложения.
  • Missing scope — без openid нельзя получить sub (уникальный ID пользователя).
  • Отсутствие одобрения для корпоративного постинга — запросы к /ugcPosts падают с 401.
  • Устаревшие токены — LinkedIn выдаёт токены с коротким сроком жизни (до 60 дней). Нужен refresh-токен.

Чек-лист внедрения LinkedIn API:

  • [ ] Зарегистрировано приложение в LinkedIn Developer Portal
  • [ ] Указаны корректные redirect URI
  • [ ] Реализована генерация и проверка state-параметра
  • [ ] Настроено хранение refresh-токена (если применимо)
  • [ ] Получено одобрение Marketing Developer Platform (если нужен корпоративный постинг)
  • [ ] Протестирован OAuth flow в песочнице LinkedIn
  • [ ] Настроен мониторинг срока действия токенов

Процесс внедрения интеграции

  1. Аудит требований — определяем, что именно нужно: авторизация, постинг или вывод профиля.
  2. Регистрация приложения в LinkedIn Developer Portal, получение client ID и secret.
  3. Запрос одобрения (если нужен корпоративный доступ) — подача заявки в Partner Program.
  4. Разработка: OAuth flow, хранение токенов, эндпоинты API.
  5. Тестирование в песочнице LinkedIn (если есть).
  6. Деплой и мониторинг — проверка обновления токенов.

Что входит в работу по интеграции

  • Аудит требований: определение необходимых scope и сценариев использования.
  • Регистрация приложения: подготовка и подача документов в LinkedIn Developer Portal.
  • Разработка OAuth-модуля: реализация flow с учётом best practices (state, refresh tokens).
  • Интеграция корпоративного постинга (опционально): разработка функционала публикации, настройка одобрения.
  • Документация: описание API эндпоинтов и инструкция по обновлению токенов.
  • Поддержка: гарантийное обслуживание в течение 30 дней после деплоя.

Сроки и стоимость

Базовая интеграция OAuth2 занимает 2–3 рабочих дня. Корпоративный постинг — от 4 до 8 недель из-за ожидания одобрения LinkedIn. Стоимость рассчитывается индивидуально, зависит от сложности и необходимости подготовки документов для партнёрской программы. Автоматизация постинга экономит до 60% времени на ручной ввод. Начните с консультации — мы оценим ваш сценарий и предложим оптимальное решение. Получите готовый модуль с документацией и гарантией работоспособности — наш опыт в интеграциях LinkedIn API насчитывает более 20 проектов для B2B-компаний. Закажите внедрение LinkedIn API уже сегодня. Свяжитесь с нами для получения консультации.

Разработка API: REST, GraphQL, WebSocket, tRPC

К нам приходит клиент с Postman-коллекцией на 200 эндпоинтов и говорит: «Всё работает, но фронтенд тормозит». Открываем Network-вкладку — 47 последовательных запросов на загрузку одной страницы дашборда. Каждый ждёт предыдущего. Это не проблема скорости сервера — это проблема архитектуры API. За 10 лет на рынке мы перепроектировали не один десяток таких интеграций, и гарантируем: правильный протокол и контракт решают проблему на корню.

Когда REST перестаёт справляться

REST хорошо работает для простых CRUD-операций. Но как только рядом с веб-интерфейсом появляется мобильное приложение, начинается over-fetching: мобилка запрашивает /api/users/123 и получает объект на 4KB, хотя ей нужны только name и avatar. Умножьте на список из 50 пользователей — 200KB трафика вместо 8KB.

GraphQL решает это через selection sets. Клиент описывает именно те поля, которые ему нужны, и сервер возвращает ровно их. На проекте с React Native + Next.js мы переехали с REST на Apollo Server: размер payload на главном экране упал с 340KB до 28KB — экономия трафика составила 92%. Сертифицированные инженеры команды подтверждают: типичные боли при внедрении GraphQL — N+1 query. Резолвер для поля author у поста вызывает SELECT * FROM users WHERE id = ? для каждого поста в списке. На странице с 20 постами — 21 запрос к базе. Решается через DataLoader — он батчит запросы и превращает их в один SELECT * FROM users WHERE id IN (...).

Что такое tRPC и чем он лучше REST/GraphQL?

Если весь стек на TypeScript (Next.js + Node/Bun), tRPC убирает целый слой проблем. Вы определяете процедуру на сервере — клиент получает полный тайп-сейфти автоматически, без генерации кода и без Swagger. Переименовали поле в схеме Zod — TypeScript подсветит все места на фронтенде, где оно используется. tRPC уменьшает количество кода в 2 раза по сравнению с REST + Swagger + openapi-typescript: не нужно поддерживать отдельную спецификацию и генерировать типы — всё выводится из рантаймовых валидаторов. Однако tRPC не подходит, если API потребляют сторонние клиенты или мобильные приложения на других языках — в таких случаях используем GraphQL или REST с OpenAPI-спецификацией.

WebSocket и реальное время: когда SSE, когда WS?

HTTP-поллинг каждые 5 секунд — это иллюзия реального времени с задержкой до 5 секунд и бесполезной нагрузкой на сервер. Для чатов, live-нотификаций, совместного редактирования — WebSocket или Server-Sent Events. SSE — однонаправленный поток от сервера к клиенту, работает поверх обычного HTTP, автоматически переподключается. Подходит для нотификаций, стриминга данных, прогресс-баров. WebSocket — двунаправленный, нужен для чатов и коллаборативных фич. Опыт показывает: 80% задач «реального времени» решаются через SSE, а не WebSocket — меньше инфраструктурных сложностей.

Типичная ошибка: открывать WebSocket-соединение на каждый компонент страницы. На одном проекте дашборд открывал 12 параллельных WS-соединений. Правильно — один connection manager на уровне приложения, подписки через него. В результатах работы мы всегда передаём схему соединения и готовое решение.

Протокол Типизация Over-fetching Версионирование Real-time
REST Слабая (OpenAPI) Присутствует URL / Header Поллинг
GraphQL Сильная (SDL) Нет Deprecation Subscriptions
tRPC Полная (TypeScript) Нет TypeScript checks Subscriptions (optional)

Swagger / OpenAPI как контракт

Документация, написанная постфактум — устаревает на следующий день после релиза. Мы пишем спецификацию OpenAPI 3.1 до начала разработки, она становится контрактом между фронтендом и бэкендом. Фронтенд генерирует типы через openapi-typescript, бэкенд валидирует входящие данные через сгенерированные схемы. Расхождение контракта с реализацией ловится на CI, а не на ревью. Для Laravel — l5-swagger или dedoc/scramble. Для Node.js — @fastify/swagger или Zod + zod-to-openapi.

Как правильно аутентифицировать API?

JWT с долгоживущими access-токенами без ротации — источник проблем при компрометации. Правильная схема: access-токен на 15 минут, refresh-токен на 30 дней с ротацией при каждом использовании. Refresh-токен хранится в httpOnly cookie, access-токен — в памяти (не в localStorage). Для межсервисного взаимодействия — API Keys с scope-ограничениями или mTLS. OAuth 2.0 с PKCE для публичных клиентов (SPA, мобилки).

Версионирование и обратная совместимость

Ломающие изменения в API без версионирования ломают клиентов. Три подхода мы используем в проектах:

Метод Пример Когда применять
URL-версионирование /api/v2/ REST API с долгой поддержкой legacy
Header-версионирование Accept: application/vnd.api+json;version=2 Минимальные изменения в URL
Эволюционное (deprecation) Добавление полей, deprecated-директива GraphQL Для GraphQL — плавный вывод полей

Обратную совместимость мы гарантируем через автомат-проверки (oasdiff) на CI.

Как мы разрабатываем API: пошаговый план

  1. Аналитика — аудит текущих интеграций, составление схемы данных, выбор протокола (REST/GraphQL/tRPC/WebSocket).
  2. Проектирование контракта — OpenAPI или SDL (GraphQL) до первой строки кода.
  3. Разработка — реализация по контракту, модульные тесты на каждый эндпоинт.
  4. Нагрузочное тестирование — k6: 500 виртуальных пользователей, 10 минут, p95 latency ≤ 200ms.
  5. Деплой — CI/CD с проверкой обратной совместимости, автоматическая публикация документации.
  6. Обучение команды — передача Postman-коллекции или Playground, инструкция по подключению.
Типичные ошибки, которые мы исключаем
  • N+1 при запросах без DataLoader.
  • Отсутствие rate limiting — DDOS через неавторизованные эндпоинты.
  • Хранение access-токена в localStorage.
  • Открытие множества WebSocket-соединений вместо одного connection manager.
  • Документация, не обновлённая после релиза.

Что входит в работу (deliverables)

  • OpenAPI 3.1 спецификация (или SDL для GraphQL).
  • Сгенерированные клиентские типы для TypeScript / Dart / Kotlin.
  • Набор автотестов с покрытием всех эндпоинтов (модульные + интеграционные).
  • Нагрузочные тесты (k6) и отчёт (p50/p95/p99 latency, RPS).
  • Документация в Swagger UI / Redoc / GraphiQL.
  • Обучение команды (2–4 часа воркшопа).
  • Поддержка в течение 30 дней после сдачи (по договору).

Наш опыт

  • 10+ лет на рынке разработки API.
  • 200+ завершённых проектов (REST, GraphQL, WebSocket, tRPC).
  • 50+ сертифицированных инженеров (AWS, Kubernetes, API Design).
  • Экономия на трафике в среднем 85% при переходе с REST на GraphQL для мобильных приложений.
  • 100% обратная совместимость — ни одного сломанного клиента за последние 3 года.

Сроки

Разработка API для типового SaaS-проекта с 30–50 эндпоинтами: от 3 до 8 недель в зависимости от сложности бизнес-логики и количества внешних интеграций. Миграция существующего REST API на GraphQL — от 2 до 6 недель. Добавление WebSocket-слоя к готовому бэкенду — от 1 до 3 недель. Стоимость рассчитывается индивидуально после аудита. Получите консультацию — свяжитесь с нами, чтобы обсудить ваш проект.