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.
Google Maps Platform suele ser la primera API de geocodificación que conecta un equipo, sobre todo porque es el nombre más conocido del sector. Su modelo de autenticación ya resulta familiar para la mayoría de los desarrolladores: una clave de API vinculada a una cuenta de facturación dentro de un proyecto de Google Cloud, enviada como parámetro de consulta en cada solicitud. Sus respuestas de geocodificación llegan como un objeto JSON con un array results, un campo status, una cadena formatted_address y un objeto anidado geometry.location que contiene la latitud y la longitud.
Lo que suele preocupar a los equipos a la hora de cambiar es el código de análisis construido en torno a esa forma exacta. Componentes de dirección, límites del viewport, identificadores de lugar: todo lo leen funciones repartidas por el código, y reescribir esas funciones es el tipo de tarea que nadie quiere programar. Este es precisamente el problema que un host compatible está diseñado para evitar.
My Geocode ofrece un host compatible con Google Maps que reproduce campo por campo el formato de solicitud y respuesta de geocodificación del propio Google. El único texto de la respuesta que nos pertenece es el de copyright, términos y privacidad; todo lo demás, incluidos los nombres de campo y el anidamiento, coincide con lo que tu código ya espera. En la práctica, migrar significa cambiar un nombre de host y una clave, no tocar un analizador. Tienes los detalles en /compatibility/google-maps/.
Lo que se mantiene igual:
Lo que cambia:
Como una clave 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, una biblioteca cliente que ya se autentica a su manera suele seguir funcionando sin modificaciones. Esa flexibilidad importa más de lo que parece, ya que en la práctica buena parte de los problemas de una migración proviene de bibliotecas que dan por hecha una forma concreta de pasar las credenciales.
En cuanto a precios, el modelo es sencillo: 2.500 solicitudes al día son gratuitas desde cualquier dirección sin necesidad de clave, y cada clave recibe además 2.500 solicitudes gratuitas al día contadas por red. A partir de ahí, es crédito prepago a 0,0001 € por solicitud o un paquete Unlimited por 50 € al mes, y todos los endpoints, incluidos todos los hosts compatibles, cuestan lo mismo. No hay niveles distintos que negociar según el producto al que llames.
Los campos extra opcionales (elevación del terreno, señales de amenazas de IP y detalles de red) están disponibles en cualquier host compatible añadiendo mg_extras=1 o una cabecera X-MG-Extras, sin romper la forma de la que depende el resto de tu código. Eso te da un camino hacia datos más completos más adelante sin una segunda migración.
Si tu integración también usa geocodificación inversa, autocompletado o consultas de códigos postales, se aplica el mismo cambio de host y clave, aunque conviene revisar la forma exacta de solicitud y respuesta de esos endpoints frente a tu código actual antes del cambio, ya que las convenciones de formato de direcciones varían según el país. Probar una parte del tráfico de producción contra el nuevo host antes del cambio completo es una forma razonable de confirmar que la forma coincide con lo que esperas. Consulta /docs/compatibility/ para ver la referencia completa de campos de todos los hosts compatibles.