Интеграции

Готовые пакеты для популярных CMS и фреймворков: ключи в настройках, отправка одной строкой, вебхуки с проверкой подписи. Все они построены на серверных SDK и одном REST API. Ключи берутся в дашборде: Приложения → ваше приложение → Настройки → API-ключи (публичный pk_… — для страниц и приложений, секретный pd_… — только для сервера).

Пакеты публикуются. Пока плагины и обвязки не появились в каталогах (wordpress.org, Bitrix Marketplace, npm, PyPI, Packagist, RubyGems, Maven Central), берите их из каталога integrations/<название> репозитория PushData: плагин WordPress и модуль Битрикс ставятся архивом каталога, пакеты фреймворков — локальной зависимостью. Настройка ниже та же.

WordPress

1. В дашборде: Провайдеры Push → Web Push → Сгенерировать ключи VAPID.
2. Загрузите папку плагина pushdata в wp-content/plugins/ и активируйте.
3. Настройки → PushData: ID приложения, публичный ключ pk_…, секретный ключ pd_… (для отправки при публикации), при включённой проверке идентичности — секрет идентичности.
4. Вставьте шорткод [pushdata_subscribe] в виджет или шаблон (или включите «Предлагать подписку автоматически»). Сайт должен работать по HTTPS.
5. Откройте сайт, подпишитесь — устройство появится в Устройства. Опубликуйте запись — push с заголовком, анонсом и ссылкой уйдёт всем подписчикам (один раз на запись; фильтр pushdata_publish_notification меняет или отменяет отправку).

Эталонный service worker плагин отдаёт с корня сайта (/pushdata-sw.js), вошедшие пользователи регистрируются как wp-<id> — им можно отправлять адресно: target: { user_ids: ['wp-42'] }. Фильтр pushdata_device_tags добавляет теги каждой подписке сайта — на мультисайте add_filter('pushdata_device_tags', fn ($tags) => [...$tags, 'city:' . $slug]), — а фильтр pushdata_publish_notification затем целится в ['tags' => ['city:' . $slug]] вместо всех.

1С-Битрикс

1. Скопируйте модуль в /bitrix/modules/pushdata/ и установите его в Marketplace → Установленные решения (при установке /pushdata-sw.js и /pushdata.js копируются в корень сайта, pushdata_identity.php — в /bitrix/tools/).
2. Настройки → Настройки продукта → Настройки модулей → PushData: ключи, автоподписка, ID инфоблоков, о новых элементах которых слать push.
3. В шаблоне сайта — любой элемент с атрибутом data-pushdata-subscribe (кнопка подписки).
4. Авторизованные пользователи регистрируются как bx-<id>; новый активный элемент выбранного инфоблока → push всем подписчикам (заголовок = название, текст = анонс, ссылка = детальная страница).

Tilda

1. Приложения → Настройки → API-ключи: секретный ключ pd_….
2. В Tilda: Настройки сайта → Формы → Webhook, URL https://api.pushdata.ru/api/v1/integrations/tilda?key=pd_… (добавьте &workflow=<id сценария>, чтобы запускать сценарий для каждой заявки). При сохранении Tilda шлёт проверочный запрос — PushData отвечает { "ok": true }.
3. В блоке формы: Контент → Приём данных → Webhook. Поля назовите Name, Email, Phone (или Имя, Почта, Телефон).
4. Отправьте заявку: контакт появится в Контакты (e-mail или телефон — внешний id, остальные поля — в metadata), запуск — в сценарии.

Ключ в URL — потому что Tilda не умеет ставить заголовки; URL хранится только в настройках Tilda, при утечке ключ перевыпускается в настройках приложения. Интеграции, которые умеют заголовки, используют Authorization: ApiKey pd_… или X-Api-Key на том же эндпоинте (receiveTildaForm в OpenAPI).

amoCRM

Входящие: amoCRM присылает свои изменения в PushData, контакты и сделки становятся контактами и событиями, а сценарий запускается, когда сделка доходит до этапа.

1. Приложения → Настройки → API-ключи: секретный ключ pd_…; Приложения → Настройки → CRM показывает готовый URL.
2. В amoCRM: Настройки → Интеграции → Webhooks → Добавить, URL https://api.pushdata.ru/api/v1/integrations/amocrm?key=pd_…, отметьте Контакт добавлен / изменён и Сделка добавлена / изменена / сменила статус.
3. Что приходит: контакт становится amocrm:<id> с именем, телефоном и e-mail (поля PHONE / EMAIL; остальные пользовательские поля — в metadata); сделка — событиями crm.lead_added, crm.lead_updated, crm.lead_stage_changed и crm.lead_stage.<id статуса> на основном контакте сделки (или на контакте-заглушке amocrm-lead:<id>, если вебхук его не назвал — добавьте вебхук по контактам, чтобы у человека был адрес). Свойства события: lead_id, title, price, status_id, old_status_id, pipeline_id, responsible_user_id, пользовательские поля сделки.
4. «Этап → сообщение»: сценарий с триггером crm.lead_stage.<id статуса> (id — из настроек воронки или из первого события в ленте контакта) и шагом SEND, где шаблон использует {{ title }} / {{ price }}; или триггер crm.lead_stage_changed с FILTER status_id eq <id>.

Bitrix24

Входящие: исходящий вебхук портала присылает id изменённой сущности, PushData забирает её через входящий вебхук портала и превращает в контакт и события.

1. В Bitrix24: Разработчикам → Другое → Входящий вебхук, права CRM; URL вида https://<портал>.bitrix24.ru/rest/<user>/<code>/ скопируйте в Приложения → Настройки → CRM → Bitrix24 REST URL (уровень администратора; код больше не показывается).
2. Разработчикам → Другое → Исходящий вебхук: URL обработчика https://api.pushdata.ru/api/v1/integrations/bitrix24?key=pd_…, события ONCRMCONTACTADD, ONCRMCONTACTUPDATE, ONCRMDEALADD, ONCRMDEALUPDATE, ONCRMLEADADD, ONCRMLEADUPDATE; его токен приложения вставьте в тот же блок настроек — каждый запрос сверяется с ним.
3. Что приходит: контакт становится bitrix24:<id> (имя, первый телефон и e-mail, metadata.bitrix24_responsible); сделка — событиями crm.deal_added / crm.deal_updated и crm.deal_stage.<STAGE_ID> (C1:NEW, WON, LOSE…) на контакте сделки (без него — заглушка bitrix24-deal:<id>), с deal_id, title, stage_id, category_id, amount, currency, closed; лид — так же с crm.lead_* и status_id.
4. «Этап → сообщение»: сценарий с триггером crm.deal_stage.WON (или crm.deal_updated + FILTER stage_id eq WON) и шагом SEND; payload прогона несёт поля сделки для шаблона.

Оба приёмника быстро отвечают 200 и пишут каждый запрос в журнал действий; недоступный портал — 502 bitrix24_error в логе исходящего вебхука. Публикация виджета / приложения в маркетплейсе любой из CRM — отдельное решение владельца.

n8n

Пакет community-узла n8n-nodes-pushdata добавляет в самостоятельно развёрнутый n8n два узла (Settings → Community nodes → Install или npm install n8n-nodes-pushdata в ~/.n8n/nodes):

• PushData — узел-действие. Notification: отправить (заголовок, текст, тип канала, аудитория — все / user id / теги / id устройств / id контактов / сегмент; необязательные поля те же, что в REST-отправке: категория, канал, диплинк, данные, расписание с местным временем, transactional, варианты A/B, цель, ключ идемпотентности — или шаблон с переменными), получить, отменить, журнал доставок. Template: список, получить. Contact: создать или обновить, получить, удалить, лента. Device: список, заменить теги, деактивировать. Workflow: запустить прогон для контакта с payload. Event: отправить пользовательское событие (запускает одноимённый сценарий, питает сегменты). AI-агенты n8n могут использовать узел как инструмент.
• PushData Trigger — узел-вебхук. Его URL вставьте в Приложения → Вебхуки с нужными событиями (NOTIFICATION_SENT / DELIVERED / OPENED / CLICKED / FAILED, WORKFLOW_COMPLETED / FAILED / FILTERED / CANCELLED); узел выдаёт по элементу на доставку { id, event, appId, timestamp, payload } и, если введён секрет вебхука, отбрасывает всё, у чего не сходится X-PushData-Signature.

Учётные данные: PushData API — секретный ключ pd_… и базовый URL (https://api.pushdata.ru). Типичные цепочки: заказ в магазине → Notification → Send на User IDs = id покупателя с включённым Transactional; CRM → Contact → Create or Update с часовым поясом и атрибутами, которые читают сегменты; NOTIFICATION_FAILED → сообщение в чат поддержки с {{ $json.payload.reason }}.

Albato и ApiMonster (российские «Zapier») подключаются к тому же REST API через свои блоки HTTP / вебхук: Authorization: ApiKey pd_…, вызовы из OpenAPI; готовые коннекторы в их каталогах — в дорожной карте.

Laravel

composer require pushdata/laravel && php artisan vendor:publish --tag=pushdata-config

.env: PUSHDATA_API_KEY=pd_… (PUSHDATA_IDENTITY_SECRET, PUSHDATA_WEBHOOK_SECRET — по необходимости).

class OrderShipped extends Notification
{
    public function via(object $notifiable): array { return ['pushdata']; }

    public function toPushData(object $notifiable): PushDataMessage
    {
        return PushDataMessage::create('Заказ отправлен', "Заказ №{$this->order->id} уже в пути.")
            ->data(['orderId' => (string) $this->order->id])
            ->clickAction(route('orders.show', $this->order));
    }
}

$user->notify(new OrderShipped($order));                 // на устройства пользователя (routeNotificationForPushData() или ключ модели)
PushData::sendNotification(['title' => 'Скидка', 'body' => 'Только сегодня.', 'target' => ['tags' => ['beta']]]);

Вебхуки: Route::post('/webhooks/pushdata', …)->middleware(VerifyPushDataWebhook::class)->withoutMiddleware(VerifyCsrfToken::class).

Symfony

composer require pushdata/symfony-notifier

.env: PUSHDATA_DSN=pushdata://pd_…@default; в notifier.yaml — texter_transports: { pushdata: '%env(PUSHDATA_DSN)%' }; фабрика PushData\Symfony\Notifier\PushDataTransportFactory с тегом texter.transport_factory.

$texter->send((new PushMessage('Заказ отправлен', 'Заказ №123 уже в пути.'))
    ->options(PushDataOptions::toUser((string) $user->getId())->data(['orderId' => '123'])));

Django

pip install django-pushdata

settings.py: INSTALLED_APPS += ["django_pushdata"], PUSHDATA = {"API_KEY": os.environ["PUSHDATA_API_KEY"]}.

from django_pushdata import client, send_notification

send_notification("Заказ отправлен", "Заказ №123 уже в пути.", user_ids=[str(order.user_id)], data={"orderId": "123"})
client().upsert_contact(str(user.pk), email=user.email)

Вебхуки: path("webhooks/pushdata/", PushDataWebhookView.as_view()) + сигнал django_pushdata.signals.webhook_received.

Rails

gem "pushdata-rails"   # bundle install && rails g pushdata:install

config/initializers/pushdata.rb: config.pushdata.api_key = ENV["PUSHDATA_API_KEY"].

PushData::Rails.send_notification("Заказ отправлен", "Заказ №#{order.id} уже в пути.", user_ids: [order.user_id], data: { orderId: order.id.to_s })
PushData::Rails.client.upsert_contact(external_id: user.id.to_s, email: user.email)

Вебхуки: include PushData::Rails::Webhook в контроллере.

Spring Boot

<dependency><groupId>ru.pushdata</groupId><artifactId>pushdata-spring-boot-starter</artifactId><version>0.1.0</version></dependency>

application.yml: pushdata.api-key: ${PUSHDATA_API_KEY} (identity-secret, webhook-secret — по необходимости).

@Autowired PushData pushdata;
pushdata.sendNotification(Map.of("title", "Заказ отправлен", "body", "Заказ №123 уже в пути.", "target", Map.of("user_ids", List.of("user-123"))));

Вебхуки: бин PushDataWebhooks — verify(body, signature); identityHash(userId) — для клиентских SDK.

NestJS

npm install @pushdata/nestjs @pushdata/node

// app.module.ts
PushDataModule.forRoot({ apiKey: process.env.PUSHDATA_API_KEY!, webhookSecret: process.env.PUSHDATA_WEBHOOK_SECRET })

// любой сервис
@Injectable()
export class OrdersService {
  constructor(private readonly pushdata: PushDataService) {}

  async shipped(order: Order) {
    await this.pushdata.sendNotification({ title: 'Заказ отправлен', body: `Заказ №${order.id} уже в пути.`, target: { user_ids: [String(order.userId)] } })
  }
}

Вебхуки: @UseGuards(PushDataWebhookGuard) (приложение создаётся с rawBody: true).

ASP.NET Core

dotnet add package PushData

builder.Services.AddPushData(builder.Configuration["PushData:ApiKey"]!);

await pushdata.SendNotificationAsync(new JsonObject { ["title"] = "Заказ отправлен", ["body"] = "Заказ №123 уже в пути.", ["target"] = new JsonObject { ["user_ids"] = new JsonArray("user-123") } });

Вебхуки: PushDataClient.VerifyWebhookSignature(rawBody, Request.Headers["X-PushData-Signature"], secret).

Своя интеграция

Всё, что делают пакеты, — вызовы REST API по спецификации OpenAPI: отправка, контакты, сценарии, вебхуки. Примеры на одиннадцати языках — в Серверных SDK; контракт устройств и событий — в Уведомлениях.