Migrar una automatización de Zapier o Make a un nuevo host de geocodificación
Las automatizaciones sin código basadas en un paso de geocodificación necesitan un enfoque de migración distinto al del código propio. Así puedes gestionar ese cambio.
Migrar desde HERE Geocoding and Search
HERE Geocoding and Search aparece mucho en software de automoción y logística, sectores en los que una cuenta empresarial con un contacto asignado y un contrato de soporte es la forma normal de trabajar. La autenticación suele ser una clave de API o un token OAuth, y las respuestas llegan como un array items en el que cada elemento incluye un objeto position y un bloque address estructurado con campos como label, countryCode y houseNumber.
Esa estructura suele estar bien documentada internamente en las empresas que dependen de ella, porque a menudo se elige HERE específicamente por la calidad de su análisis de direcciones en una región concreta o por su integración de rutas en otra parte del stack. Una migración que rompe la forma de la respuesta rompe todo ese código posterior a la vez, y por eso aquí la compatibilidad importa más que el coste de cambiar la propia cuenta.
El host compatible con HERE de My Geocode reproduce el array items y sus campos anidados position y address exactamente como los devuelve HERE, y solo sustituye el texto de copyright, términos y privacidad. Consulta /compatibility/here/ para ver la referencia de campos. En la mayoría de los casos, el cambio necesario en el código de la aplicación es el nombre de host y la clave, y nada del código que lee items[0].position o items[0].address.label.
Los equipos empresariales que dejan HERE suelen tener la geocodificación conectada en varios servicios en lugar de uno, así que ayuda hacer primero un inventario de todos los puntos de llamada: trabajos por lotes, formularios de validación de direcciones, rutas de reparto y cualquier herramienta de administración suelen llamar a la misma API de forma independiente. Trasladarlos servicio a servicio, empezando por algo con poco tráfico, es una forma sensata de validar el nuevo host en condiciones reales antes de que cambien las llamadas con más volumen.
En cuanto a la autenticación, una clave emitida por My Geocode se puede enviar en una cabecera X-API-Key, en una cabecera Authorization: Bearer, con autenticación HTTP Basic o en un parámetro de consulta. Si tu biblioteca cliente de HERE ya se autentica de una forma concreta, apuntarla al nuevo host con una nueva clave suele ser suficiente, ya que la biblioteca en sí no necesita cambiar.
Los precios eliminan una capa de negociación que suelen conllevar los contratos empresariales. No hay una estructura de cuentas por niveles: 2.500 solicitudes al día son gratuitas sin clave, cada clave añade otras 2.500 solicitudes gratuitas al día contadas por red y, por encima de eso, es crédito prepago a 0,0001 € por solicitud o una clave Unlimited por 50 € al mes. Todos los endpoints, incluido este host compatible, cuestan lo mismo, así que no hay una negociación aparte para el volumen de geocodificación frente al volumen de búsqueda o de autosugerencias.
Si parte de tu uso de HERE son autosugerencias y no geocodificación directa, conviene tratarlo como un paso de migración propio, ya que los endpoints de tipo autocompletado tienen su propia forma de respuesta y un patrón de solicitud que depende de entradas parciales, y merecen pruebas separadas en lugar de integrarse en el cambio de la geocodificación. El uso de la cuota en cada solicitud, incluido el host compatible, es visible mediante cabeceras de respuesta como X-Quota-Used y X-Credits-Remaining, documentadas en /docs/rate-limits/.