API de producción
Consulta y reintentos
Reintenta sin riesgo, respeta Retry-After, actúa en cuanto energy_usable sea true y deja de consultar solo cuando las dos banderas finales sean true.
En esta página
Rentron no envía webhooks ni callbacks. GET /v1/energy/orders/{id} es la fuente de la verdad.
Ritmo de consulta recomendado
Tras crear el pedido, consulta Location al cabo de 1, 2 y 5 segundos, y después cada 10 segundos. Añade una pequeña variación aleatoria si sigues muchos pedidos a la vez.
Envía tu propia transacción en cuanto energy_usable sea true: para entonces la Energy ya está en la dirección. Sigue consultando después y para solo cuando lifecycle_final === true y delivery_final === true.
Matriz de reintentos
| Resultado | Qué hacer |
|---|---|
| Error de red o tiempo agotado en un GET | Reintenta con espera creciente. |
| Tiempo agotado al crear el pedido | Repite el mismo cuerpo exacto y el mismo client_request_id. |
429 |
Espera los segundos que indique Retry-After. |
500 o 503 en un GET |
Reintenta con espera creciente y variación aleatoria. |
400, 413, 415 |
Corrige la petición; un reintento automático no sirve. |
401 |
Corrige la credencial, la firma, la marca de tiempo o la lista de IP. |
409 por conflicto de idempotencia |
Para e investiga qué IDs de cliente se están reutilizando. |
Tres señales: una para actuar, dos para parar
energy_usable es la señal con la que actúas. Se pone en true ya en available, alrededor de un minuto antes de delivered, y significa que la Energy está en la dirección y se puede gastar. Esperar a delivered solo gasta alquiler que ya has pagado.
delivery_final y lifecycle_final son las señales con las que paras. delivery_final cierra el intento de entrega y sigue en false mientras el pedido está en available, porque ahí la entrega todavía no se ha verificado de forma independiente. lifecycle_final cierra la duración del alquiler: después de una entrega correcta, un pedido sigue activo hasta rental_finished. Parar en energy_usable, en una sola bandera o en un solo estado corta el bucle antes de tiempo.
Límites de peticiones
Los límites se aplican por separado al endpoint público de hora, al tráfico autenticado y a la creación de pedidos. No adivines los valores: trata el 429 y el Retry-After como el contrato.
Rentron