Cómo migrar de OneSignal a Pushwoosh

OneSignal le puso un techo duro a su plan gratis. Muy pronto, el push móvil y los mensajes in-app dejan de ser gratuitos arriba de 1.000 usuarios activos mensuales. Las cuentas nuevas chocan con el límite el 1 de septiembre de 2026, las existentes el 1 de octubre. Si tu app supera los mil usuarios activos al mes, tenés 3 caminos: quedarte y pagar, recortar audiencia, o migrar.

Qué cambia y cuándo

Source: OneSignal

• El plan gratis sigue funcionando por debajo de 1.000 MAU. Arriba de eso, el push móvil y el in-app pasan a un nivel pago.
• Las fechas: el límite aplica a cuentas nuevas desde el 1 de septiembre de 2026 y a cuentas existentes desde el 1 de octubre de 2026, según el FAQ de facturación de OneSignal.
• El umbral: menos de 1.000 MAU para push móvil e in-app. Si lo cruzás, esos canales dejan de enviar hasta que actualices el plan.
• Lo que no cambia: web push, email y SMS siguen funcionando dentro de los mismos límites de plan que antes. El cambio es específico para mobile.
• Los journeys también se ven afectados: cualquier paso de journey que envíe un push o un mensaje in-app simplemente salta las suscripciones móviles.
• Borrar suscriptores no es una salida. Si borrás suscripciones móviles que estuvieron activas en los últimos 30 días, tu plan recién puede reactivarse 30 días después del borrado, y solo si te mantenés bajo el límite durante todo ese período.

Cómo funciona la migración

Si decidiste migrar, esta es la parte que cambia cómo planeás el proceso: nosotros corremos la migración por vos. Tu parte del trabajo son tres cosas: un archivo de exportación, tus credenciales de push, y cambiar el SDK en tu próxima versión de la app. Todo lo demás (limpiar los datos, mapear plataformas, recrear tags, importar la audiencia, verificar la entregabilidad) corre por nuestra cuenta.

El cambio corre en dos vías a la vez. Una importación única traslada tu base existente, así tu audiencia queda alcanzable desde el primer día, antes de que un solo usuario actualice la app. El SDK después toma el control de cada dispositivo a medida que su dueño instala la nueva versión. Necesitás las dos cosas, y ninguna bloquea a la otra.

1. Qué podemos migrar y qué no

No tenés que auditar esto vos mismo. Acá está el panorama completo de entrada, para que nada te sorprenda a mitad de la migración.

Cuánto tiempo lleva

El cambio de SDK y un envío de prueba limpio son un día de trabajo para un desarrollador. La importación corre en paralelo de nuestro lado, y es lo que mantiene tu alcance intacto desde el primer día: los dispositivos importados son entregables antes de que nadie actualice la app. La audiencia propia de tu app después se traslada al SDK de Pushwoosh al ritmo en que tus usuarios instalan la nueva versión, lo que lleva semanas y nunca llega al último dispositivo. Por eso existe la importación.

El orden importa:

1. Exportá tu audiencia. Enviános tu app_id de OneSignal y una App API key, y nosotros hacemos la exportación, o exportá el CSV vos mismo. Detalles abajo.
2. Enviános tus credenciales de push. Las mismas claves con las que OneSignal ya envía. Las subimos antes de la importación, para que cada dispositivo importado sea entregable.
3. Cambiá el SDK. Quitá el SDK de OneSignal, agregá el SDK de Pushwoosh, inicializalo con tu código de aplicación de Pushwoosh y tu device API token. Los pasos por plataforma están en las Versiones A a C.
4. Verificá la entrega. Registrá un dispositivo de prueba y mandate un push a vos mismo antes de tocar el tráfico de producción.
5. Aprobá la planilla de tags. La armamos a partir de tu exportación; vos tachás los tags que ya no usás y marcás los que pueden tener varios valores. Importamos y recreamos tus segmentos.
6. Pasá el envío. Una vez que la entrega de prueba está limpia y la importación confirmada, apuntá tus campañas a Pushwoosh y dejá de enviar desde OneSignal.

2. Exportá tu audiencia

Opción A (recomendada): lo hacemos por vos. Enviános tu app_id de OneSignal y una App API key, y nosotros hacemos la exportación. Tu parte termina acá.

Opción B: lo hacés vos. En OneSignal, andá a Audience > Subscriptions y exportá el CSV, o llamá al endpoint de exportación:

curl -X POST 'https://api.onesignal.com/players/csv_export?app_id=YOUR_APP_ID' \
  -H 'Authorization: Key YOUR_APP_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"extra_fields":["external_user_id","timezone_id","notification_types"]}'

La respuesta devuelve csv_file_url, un CSV comprimido en gzip que queda disponible para descargar durante tres días.

Source: OneSignal

Estas columnas tienen que estar en el archivo. Cualquier otra cosa es opcional y la ignoramos.

Nota: external_user_id y timezone_id no forman parte de la exportación por defecto. Pedilos explícitamente con el parámetro extra_fields de arriba, o con el selector de columnas del dashboard.

3. Enviános tus credenciales de push

Son las mismas credenciales que OneSignal ya usa para enviar en tu nombre, así que no hay que crear nada nuevo. Nosotros no podemos sacarlas de OneSignal: una clave subida nunca vuelve a ser descargable, así que este paso es tuyo.

Subimos las credenciales a tu aplicación de Pushwoosh antes de que empiece la importación. Este orden importa: una importación sin credenciales produce una base de datos llena de dispositivos a los que no se les puede entregar nada.

4. Revisá tus tags y segmentos

Source: OneSignal

Los tags se migran, y vos no tenés que inventariarlos. En OneSignal un tag es un simple string clave/valor sin tipo declarado. En Pushwoosh cada tag se declara una vez por aplicación con un tipo (String, Integer, Boolean, Date, List o Price), y recién ahí guarda valores.

Apenas tenemos tu exportación, te mandamos una planilla de revisión de tags armada a partir del archivo mismo. Lista cada tag que encontramos, con los datos completos: valores de muestra, cuántos dispositivos tienen un valor, y el tipo que proponemos. Tu parte son dos columnas: tachar los tags que ya no usás, y marcar los que pueden tener varios valores a la vez. Todo lo demás es una propuesta que podés aprobar tal cual está.

Por qué preguntamos en vez de adivinar: el tipo de un tag queda fijo una vez creado, así que un tag multi-valor que creamos como String simple hay que borrarlo y reimportarlo. Un tag que parece de un solo valor en la exportación es justo el caso que no podemos detectar a partir de los datos. Si no recibimos respuesta, importamos cada tag con el tipo que inferimos y te contamos cuáles adivinamos.

Los segmentos se reconstruyen. La API de OneSignal puede filtrar una exportación por segmento y listar los nombres de tus segmentos, pero no devuelve los filtros detrás de ellos, así que no hay nada para importar. Dos caminos posibles:

1. Reconstruir las condiciones (recomendado). Enviános tu lista de segmentos con sus filtros; capturas de pantalla sirven. Los recreamos sobre los tags importados. Los segmentos reconstruidos son dinámicos: siguen actualizándose a medida que tu audiencia cambia.
2. Congelar la membresía. Tomamos una exportación por segmento y marcamos cada archivo con un tag identificador, por ejemplo os_segment = vip_users. Es rápido, pero el resultado es una foto fija que no se actualiza sola.

Los segmentos armados sobre datos de comportamiento propios de OneSignal (cantidad de sesiones, tiempo de juego, “Active Users”, “Engaged Users”) no se pueden reproducir al momento de importar, porque ese historial se queda en OneSignal. Sus equivalentes en Pushwoosh empiezan a llenarse en cuanto nuestro SDK sale en tu app.

5. Qué hacemos de nuestro lado

1. Creamos y configuramos tu aplicación de Pushwoosh y subimos las credenciales del paso 3.
2. Limpiamos la exportación: sacamos las filas dadas de baja y las filas con token vacío, mapeamos los códigos de plataforma de OneSignal a los nuestros, convertimos los tags, y mapeamos tu external_user_id a nuestro User ID.
3. Creamos el esquema de tags, y después importamos la audiencia en lotes, verificando cada lote.
4. Mandamos un push de prueba a un grupo de control chico y comparamos el resultado con lo que se espera.
5. Te reportamos: cuántas suscripciones había en el archivo, cuántas se importaron, y el motivo de cada fila que salteamos.

6. Lanzá el SDK de Pushwoosh en tu próxima versión de la app

La importación hace que tu audiencia existente sea alcanzable de inmediato, pero es un puente, no el destino final. Solo el SDK de Pushwoosh dentro de tu app puede tomar un token nuevo cuando el sistema operativo lo rota (reinstalación, restore, actualización de SO), registrar a los usuarios que instalan después de la migración, y reportar aperturas, mensajes in-app y desinstalaciones.

Quitá el SDK de OneSignal en la misma versión. Dos SDKs de push en un mismo build compiten por los mismos callbacks de notificación, y esa combinación no la probamos. Que OneSignal siga enviando mientras la nueva versión se despliega es normal y esperable; que los dos SDKs convivan dentro de un mismo build no lo es. Los pasos específicos por plataforma están en las Versiones A a C, abajo.

7. Web push: cómo vuelven tus suscriptores

El web push no se importa, y es un límite técnico real, no una decisión de Pushwoosh. Una suscripción de web push queda firmada con el par de claves VAPID de quien la creó, y la clave privada de OneSignal nunca sale de OneSignal — su propia documentación marca las claves de suscripción web como disponibles solo para los SDKs de OneSignal. Ningún proveedor puede importar las suscripciones web de otro proveedor. Lo que sí funciona es la re-suscripción silenciosa:

1. Quitá el snippet de OneSignal y desregistrá explícitamente su service worker. Dejar el worker viejo activo hace que compitan dos workers en el mismo dominio.
2. Instalá el Pushwoosh Web Push SDK, con nuestro service worker en la raíz de tu dominio.
3. Inicializalo con tu código de aplicación y tu device API token (apiToken), y después habilitá la suscripción automática (autoSubscribe: true, o llamá a Pushwoosh.subscribe()). Sin el token, las llamadas del SDK vuelven como 401.

Un visitante que vuelve queda re-suscripto en silencio. El permiso de notificaciones que el navegador guarda le pertenece a tu dominio, no a tu proveedor anterior, así que no aparece un segundo prompt y el usuario no nota nada. Qué tan rápido se recupera tu base depende de qué tan rápido vuelve la gente: la mayoría de la audiencia suele volver dentro de la primera semana, con una cola que se extiende durante el mes siguiente.

Tres casos a tener en cuenta:

• Los visitantes que bloquearon las notificaciones no se pueden re-suscribir. El navegador se niega y no les vuelve a mostrar el prompt. Quedan afuera, que es el resultado correcto.
• Los visitantes que se dieron de baja en tu sitio mientras el permiso del navegador seguía concedido quedarían re-suscriptos en silencio. Es técnicamente válido, pero trae de vuelta a gente que se fue a propósito. Si tenés una lista de exclusión (por tu propio user id o email), enviánosla y excluimos a esos usuarios de cada campaña. Si no la tenés, te recomendamos suscribir con un clic explícito (una campanita o un prompt) en vez de automáticamente.
• Si tu web push corría en un subdominio provisto por tu proveedor anterior en lugar de tu propio dominio, el permiso le pertenece a ese subdominio. Esos suscriptores no se pueden recuperar y tienen que volver a aceptar en tu sitio. Revisá qué configuración tenés antes de planear el cambio.

8. Qué esperar después de la importación

• Un dispositivo puede aparecer duplicado por un tiempo. El registro importado lleva el identificador de OneSignal; en cuanto nuestro SDK corre en ese mismo dispositivo, se registra con su propio identificador. El registro viejo se elimina por el tracking de desinstalación o la limpieza automática por 90 días de inactividad. Enviar external_user_id mantiene los dos registros bajo un mismo perfil de usuario mientras tanto.
• Los tokens muertos se van con tu primera campaña. Apple y Google solo revelan que un token es inválido cuando efectivamente se envía un mensaje, así que el primer envío después de la migración también limpia tu base.
• Tu número importado va a ser menor que el contador de OneSignal. Las filas dadas de baja, las filas con token vacío y las filas de web push quedan excluidas por diseño. Nuestro reporte te dice exactamente cuántas cayeron en cada grupo.

9. Dónde hacer clic

Las rutas exactas para los ítems de tu lado, para que nadie tenga que rebuscar en los dashboards.

Checklist antes del 1 de octubre

Tené esto abierto mientras avanzás. Nada acá necesita un formulario para descargar.

Versión A: iOS y Android nativos

iOS. Agregá el Pushwoosh iOS SDK, y después configurá dos claves en Info.plist: Pushwoosh_APPID con tu código de aplicación de Pushwoosh y PW_API_TOKEN con tu device API token. Llamá a registerForPushNotifications() donde hoy disparás el prompt de OneSignal, y seguí el quick start de iOS para el snippet de inicialización exacto de tu versión de SDK. Quitá el SDK de OneSignal y su llamada de registro para que los dos no pidan tokens al mismo tiempo.

Android. Agregá la dependencia com.pushwoosh:pushwoosh-firebase, y después agregá dos entradas meta-data dentro del tag <application> de AndroidManifest.xml: com.pushwoosh.appid con tu código de aplicación y com.pushwoosh.apitoken con tu device API token. Llamá a Pushwoosh.getInstance().registerForPushNotifications() desde tu lógica de inicialización. Tu configuración de Firebase queda igual, con google-services.json en el proyecto; las credenciales de FCM van en el Control Panel, bajo la configuración de tu plataforma Android.

Configurá tus tags con setTags() y tu identificador de usuario con setUserId() en los mismos puntos donde llamabas a los equivalentes de OneSignal, para que la segmentación siga funcionando después del cambio.

Versión B: Flutter y FlutterFlow

FlutterFlow envuelve el SDK de Flutter de Pushwoosh, así que la migración es sobre todo configuración, no código.

1. Agregá el paquete de Flutter de Pushwoosh como dependencia personalizada en tu proyecto.
2. En una custom action, inicializá el SDK con tu código de aplicación y registrate para notificaciones push, siguiendo el quick start de Flutter para la API de inicialización actual.
3. Configurá las credenciales nativas como lo hace cualquier app Flutter: Pushwoosh_APPID y PW_API_TOKEN en Info.plist para iOS, com.pushwoosh.appid y com.pushwoosh.apitoken en AndroidManifest.xml para Android.
4. Quitá la integración de OneSignal para que los dos SDKs no se registren a la vez.
5. Mapeá tags y user id con setTags() y setUserId() en tus custom actions.

Versión C: React Native

1. Instalá el plugin: npm install pushwoosh-react-native-plugin --save, y después pod install para iOS.
2. Inicializá y registrá en tu componente raíz:

import Pushwoosh from 'pushwoosh-react-native-plugin';

Pushwoosh.init({ pw_appid: "YOUR_APPLICATION_CODE" });
Pushwoosh.register();

3. Agregá el device API token de forma nativa: PW_API_TOKEN en Info.plist para iOS, com.pushwoosh.apitoken como meta-data en AndroidManifest.xml para Android. En Android mantené google-services.json en el proyecto — las credenciales de FCM en sí viven en el Control Panel.
4. Quitá el paquete de React Native de OneSignal y su llamada de init.
5. Trasladá tus tags y tu user id con setTags() y setUserId() de la API del plugin.

FAQ

Cualquier pregunta en el camino va para tu contacto de onboarding en Pushwoosh. Preferimos responder antes de la importación que reconciliar números después.