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 ipstack
ipstack se autentica con un parámetro de consulta access_key y devuelve una respuesta JSON con campos como type (ipv4 o ipv6), continent_code, latitude, longitude y, en los planes superiores, un objeto anidado connection que contiene los detalles del sistema autónomo y del ISP por separado de los campos de nivel superior. Esa estructura de connection anidada es algo más elaborada que los formatos más planos de algunos competidores, lo que conviene a las aplicaciones que quieren tratar los detalles del ISP y de la red como una agrupación lógica propia en lugar de mezclarlos con los campos de ubicación.
Migrar este tipo de estructura anidada requiere algo más de cuidado que una respuesta plana, simplemente porque hay más puntos en el árbol de la respuesta en los que un nombre de campo podría diferir. Conviene probar específicamente las rutas anidadas, no solo los campos de nivel superior, antes de dar por completada una migración.
El host compatible con ipstack de My Geocode reproduce la estructura completa, incluidos los campos type, continent_code, latitude y longitude y el objeto anidado connection, y solo cambia el texto de copyright, términos y privacidad. Los detalles de referencia están en /compatibility/ipstack/. El código que lee response.connection.isp o response.type debería recibir la misma forma una vez apuntado al nuevo host con una nueva clave.
Como en My Geocode las consultas de IP funcionan por completo de principio a fin, los resultados aquí son concretos y no se describen solo en cuanto a la forma. Una consulta de una dirección determinada devuelve país, región, ciudad, coordenadas y detalles de conexión en directo, verificados con una capa de caché que mantiene actualizada la geolocalización de IP en lugar de depender de actualizaciones por lotes poco frecuentes.
Notas específicas de migración para integraciones de ipstack:
- El patrón del parámetro de consulta
access_keyse corresponde directamente con nuestra opción de parámetro de consulta, o puedes pasar a una cabeceraX-API-Key, aAuthorization: Bearero a autenticación HTTP Basic durante la misma migración si prefieres cambiar también el estilo de autenticación - Los campos extra opcionales (elevación cuando corresponda, detalles de amenazas de IP, información de red más detallada) están disponibles mediante
mg_extras=1o una cabeceraX-MG-Extras, y se suman a la forma estándar en lugar de sustituir ninguna parte de ella - Si tu integración revisa campos de
securitypara la detección de proxies o amenazas, esos valores concretos forman parte de los extras opcionales y no de la respuesta de compatibilidad básica, así que confirma de qué campos depende realmente tu código antes de dar por hecha una paridad total
En cuanto a precios, 2.500 solicitudes al día son gratuitas sin ninguna clave, y cada clave recibe además sus propias 2.500 solicitudes gratuitas al día, contadas por red. Más allá de eso, se aplica de forma uniforme el crédito prepago a 0,0001 € por solicitud o una clave Unlimited a 50 € al mes, y todos los endpoints, incluido este host de compatibilidad, tienen el mismo precio. Para las aplicaciones que usan el objeto connection de ipstack como una agrupación de datos propia en sus modelos internos, esa agrupación se mantiene sin cambios, lo que conserva intactos el código posterior, los paneles y los almacenes de datos construidos sobre esa estructura.