Changelog
14/10/2026 · Certific@ unavailable: immediate 503 with Retry-After

Certific@ unavailable: immediate 503 with Retry-After

14/10/2026

Until today, when SEPE's Certific@ service was unavailable, a company certificate query (GET /sepe/certifica) could take about 12 seconds and end in a 500 with a "timed out" message that suggested checking the certificate. From today the API answers straight away with 503 Service Unavailable, maintenance: true and a Retry-After header:

HTTP/1.1 503 Service Unavailable
Content-Type: application/json
Retry-After: 120
Respuesta 503
{
  "success": false,
  "message": "SEPE: El servicio Certific@ no está disponible en este momento. Inténtalo de nuevo más tarde.",
  "status": 503,
  "errors": {
    "sepe": ["SEPE: El servicio Certific@ no está disponible en este momento. Inténtalo de nuevo más tarde."]
  },
  "maintenance": true,
  "retry_after": 120
}

It applies to every Certific@ endpoint: sending the company certificate (POST /sepe/certifica), sending it by XML (POST /sepe/certifica/xml), the duplicate (GET /sepe/certifica), the list (GET /sepe/certifica/list) and the detail (GET /sepe/certifica/detail).

While the Certific@ service is still unavailable, subsequent requests also get a 503 immediately, sometimes with the message SEPE: El SEPE no responde. Inténtelo de nuevo en unos minutos.. In both cases, Retry-After (like retry_after in the body) gives the seconds left until it is worth trying again.

The body format does not change (success, message, status, errors, maintenance, retry_after).

What to check in your integration:

  • A 503 is not a problem with your certificate or with the data you sent. Do not switch certificates or change the request: SEPE is unavailable.
  • Wait for what Retry-After says and do not retry in a loop: retrying early returns the same 503.
  • If you handled the Certific@ 500 as a special case, move it to the logic you already have for 503 with maintenance: true. Status codes are in SEPE errors.