El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
En qué se equivoca la facturación por producto sobre cómo se usan las API
Abre el registro de solicitudes de casi cualquier aplicación que use datos de ubicación y no encontrarás un solo tipo de consulta ejecutándose de forma aislada. Un formulario de registro geocodifica una dirección, comprueba la IP para obtener una coincidencia aproximada de red y marca el registro con una zona horaria, todo en los mismos pocos cientos de milisegundos. No son tres casos de uso distintos que casualmente comparten proveedor de API. Son un único flujo de trabajo que toca tres tipos de datos.
La facturación por producto finge lo contrario. Pone precio a la geocodificación en un plan, a las consultas de IP en otro y a los datos de zona horaria o de elevación como complementos opcionales con sus propias tarifas, como si una empresa que necesita uno de ellos no fuera a necesitar los demás. En la práctica ocurre lo contrario: necesitar uno suele ser señal de que necesitas al menos otro más. Un proceso de pago de comercio electrónico que geocodifica una dirección de envío casi seguro que también quiere saber en qué zona horaria programar una franja de entrega. Una comprobación de fraude que examina una dirección IP normalmente quiere cotejarla con una dirección registrada.
Pusimos precio a My Geocode como un solo producto con una sola tarifa. Cada endpoint, geocodificación, consulta de IP, zona horaria, elevación, código postal, y cada host compatible, cuesta exactamente lo mismo por solicitud. No hay una lista de precios aparte que cuadrar ni un plan que añada datos de zona horaria solo después de haber pagado ya un plan de geocodificación. Una solicitud es una solicitud, sea cual sea el endpoint al que llegue.
No es solo una comodidad para el cliente. Refleja cómo se hace realmente el trabajo subyacente. Atender una consulta a un endpoint no tiene un coste radicalmente distinto al de atender una consulta a otro, a la escala a la que funcionan la mayoría de las aplicaciones. Dividirlos en productos separados con precios separados no refleja una diferencia real en lo que cuesta responder a la solicitud. Refleja cuántas líneas separadas puede poner un proveedor en una factura.
La facturación por producto también hace más difícil razonar sobre tu propio uso. Si la geocodificación se factura de una forma y las consultas de IP de otra, estimar la factura del mes que viene implica seguir dos contadores con dos estructuras de tarifas y esperar que la mezcla de llamadas no cambie de una forma que altere el total de manera impredecible. Una tarifa plana y unificada reduce esa estimación a un solo número: total de solicitudes por un precio. Cualquiera que prepare un presupuesto para su integración puede hacer esa cuenta en el reverso de un sobre.
Hay una suposición más profunda escondida en los precios por producto que creemos que simplemente es errónea: que los distintos tipos de datos de ubicación sirven a clientes distintos. En nuestra experiencia sirven al mismo cliente, en distintos momentos de la misma solicitud. Una plataforma logística, un flujo de registro y un sistema antifraude combinan datos de geocodificación, de IP y de zona horaria en una sola decisión. Unos precios que fingen que son mercados separados obligan a los clientes a pagar de más por un paquete que usan de forma desigual o a hacer malabares con varios proveedores para evitarlo. Una tarifa, una lista de endpoints, es la respuesta más sencilla y más honesta.