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.
Por qué los entornos de pruebas deberían ser gratuitos
Algunas API ofrecen un entorno sandbox funcionalmente separado de producción: claves distintas, a veces endpoints distintos, en ocasiones su propia estructura de precios o sus propios límites más restrictivos. La intención es razonable: dar a los desarrolladores un espacio seguro para probar sin tocar el uso real ni la facturación real. En la práctica, un sandbox que requiere su propio registro, su propia clave o su propio paso de actualización de pago añade fricción justo en el momento en que un desarrollador intenta decidir si tu API merece siquiera la pena.
No tenemos un sandbox aparte. Las pruebas y la producción usan la misma cuota gratuita diaria: 2.500 solicitudes al día desde cualquier dirección sin clave, y otras 2.500 al día cuando añades una clave, contadas por red. No hay un modo de prueba aparte con sus propios límites que aprender ni un plan de pago que ponga las pruebas serias detrás de una compra. Aquello con lo que construyes durante la evaluación es exactamente el mismo sistema en el que despliegas, con exactamente la misma cuota gratuita, antes de gastar un solo euro.
Esto importa porque un sandbox que se comporta aunque sea un poco distinto de producción está probando el sandbox, no tu integración. Si un sandbox aparte usa datos de respuesta simplificados o falsos en lugar del conjunto de datos real, descubres las peculiaridades de los datos reales solo después de salir a producción, lo que anula buena parte de lo que las pruebas deberían detectar. Probar con el sistema real, con datos reales y usando la cuota gratuita real significa que lo que aprendes durante la evaluación es cierto para lo que ejecutarás en producción.
No poner el acceso al sandbox detrás de un paso de pago aparte tiene un coste para nosotros: una parte de ese tráfico de pruebas gratuito nunca se convertirá en una cuenta de pago, el mismo intercambio que en cualquier nivel gratuito generoso. Creemos que ese coste merece la pena, porque la alternativa traslada exactamente el incentivo equivocado a un desarrollador que decide si construir o no sobre tu API. Un modo de prueba de pago o muy restringido pide a alguien que se comprometa económicamente antes de saber si el producto encaja con su caso de uso. Una vía de pruebas gratuita y totalmente funcional permite tomar esa decisión por sus méritos, después de probarlo de verdad.
Nada de esto significa que las pruebas no tengan ningún límite. Las mismas 2.500 solicitudes al día que cubren un uso ligero en producción también cubren las pruebas, y una prueba de carga a gran escala contra esa cuota chocará con el mismo techo que una pequeña integración en producción. Es intencionado. El nivel gratuito es lo bastante generoso para una evaluación real, no infinito, y usarlo como tu entorno de pruebas permanente para un producto de gran volumen es algo distinto de usarlo para confirmar que una integración funciona antes de pasar al uso de pago.
Un sandbox debería responder con honestidad a una sola pregunta: si esto funciona como espero, usando lo real. Cobrar por esa respuesta, o darla con cualquier cosa que no sea lo real, anula el propósito en ambos casos.