Sincroniza bajas con tu base de datos

Cada vez que el indicador subscribed de un contacto se desactiva — ya sea por una edición manual, la página de baja alojada, un rebote, o una queja de spam — Bitelio emite contact.unsubscribed. Un flujo de trabajo que escuche ese evento puede reenviarlo directamente a tu backend mediante un paso WEBHOOK.

Configuración

app.post('/bitelio/unsubscribes', async (req, res) => {
  if (req.header('authorization') !== `Bearer ${process.env.BITELIO_WEBHOOK_SECRET}`) {
    return res.status(401).end();
  }

  const { contact, event } = req.body;
  await db.user.update({
    where: { email: contact.email },
    data: {
      emailSubscribed: false,
      emailUnsubscribedReason: event.reason ?? 'user_action',
    },
  });

  res.status(204).end();
});

Reflejar las resuscripciones

Para la dirección opuesta del indicador, clona la misma estructura en un segundo flujo de trabajo disparado en contact.subscribed. No fusiones los dos en un flujo único con ramas — un par de flujos de trabajo pequeños y de propósito único es mucho más fácil de vigilar.

La dirección inversa

Cuando la copia autoritativa vive de tu lado — digamos que un usuario cambia su preferencia de correo dentro de tu propia página de ajustes — envía el cambio a Bitelio con PATCH /contacts/:id desde tu backend:

curl -X PATCH https://api.bitelio.com/contacts/cnt_abc \
  -H "Authorization: Bearer sk_your_secret_key" \
  -d '{"subscribed": false}'

Ten en cuenta que esta actualización también emite contact.unsubscribed, así que el webhook que construiste arriba reflejará el cambio de vuelta a tu manejador. Como la escritura es idempotente, el ciclo normalmente es inofensivo — simplemente no te sorprenda.

Qué sigue