Social Security

Connect your applications to Social Security services.

HTTP header parameters

• Authorization (string): API authorisation. Example: Bearer {token}
• X-Cert-Secret (string) : Secret key associated with the client certificate.

Base URL

https://api.saltra.es/api/v4/seg-social

Errors

Errors returned by the Social Security API, or validation errors.

Response parameters

• success (boolean) : Returns “true” when everything is correct, and “false” when there are errors.
• message (string) : The response message.
• errors (array) : Errors captured by the API, either from Social Security or validation errors.
  • tgss: Errors related to Social Security.
  • regimen: Validation errors.
• maintenance (boolean) : Set when Social Security is under maintenance.
• retry_after optional (integer) : On 503 with maintenance: true or with retryable: true: the same seconds as the Retry-After header. If it is missing, use the header.
• retryable optional (boolean) : true on 503 responses where we could not communicate with the authority; retry after Retry-After. It is absent on 424 and on the unknown-outcome 503 of a write.

Response

{
  "success": false,
  "message": "Página no operativa, inténtelo de nuevo más tarde. StatusCode: 500",
  "status": 500,
  "data": [],
  "errors": {
    "tgss": [
      "Página no operativa, inténtelo de nuevo más tarde. StatusCode: 500"
    ],
    "regimen": ["El campo regimen es obligatorio."]
  },
  "maintenance": true
}

Status codes

When the failure is on the authority’s side (TGSS/RED System, SEPE, DEHU, AEAT, Navarre Tax Office) or in the connected system, the HTTP code tells you whether retrying is worthwhile. The body always follows the usual error format (success, message, status, data, errors): read it on every status code; the reason is in message.

Saltra’s validation errors are still 422 (do not retry until the data is fixed).

Example of a retryable 503:

HTTP/1.1 503 Service Unavailable
Content-Type: application/json
Retry-After: 60
X-Saltra-Error: organism-unavailable

{
  "success": false,
  "message": "Error de conexión de SALTRA con el (SISTEMA RED).",
  "status": 503,
  "data": [],
  "errors": {
    "tgss": ["Error de conexión de SALTRA con el (SISTEMA RED)."]
  },
  "maintenance": false,
  "retryable": true,
  "retry_after": 60
}

Maintenance

When Social Security or the RED System is under maintenance or not operational, the API responds 503 with maintenance: true and a Retry-After header with the seconds to wait. Retrying earlier returns the same 503.

HTTP/1.1 503 Service Unavailable
Content-Type: application/json
Retry-After: 300

{
  "success": false,
  "message": "SISTEMA RED: No operativo o en mantenimiento, inténtelo de nuevo más tarde.",
  "status": 503,
  "errors": {
    "tgss": ["SISTEMA RED: No operativo o en mantenimiento, inténtelo de nuevo más tarde."]
  },
  "maintenance": true,
  "retry_after": 300
}

Rate limits

Authenticated requests are limited to 80 per minute for reads (GET) and 120 per minute for writes (POST). The limit is counted per certificate (if X-Cert-Secret is sent) or, failing that, per authenticated user, and per route. Unauthenticated requests are limited to 60 per minute per IP. The heavy-integration endpoints —GET /employee-situations and GET /ta-info-for-nss from Social Security, and GET /contrata/data from SEPE— share a lower combined quota of 30 requests per minute per certificate (or user): using one reduces the quota of the other two.

Saltra reports your quota status in the headers of every response, so you can pace your calls before running out.

Example of a successful response:

HTTP/1.1 200 OK
X-Ratelimit-Limit: 80
X-Ratelimit-Remaining: 45
X-Ratelimit-Reset: 1786012860

X-Ratelimit-Reset is an absolute instant, not a countdown: it stays the same across every response in the same window and only moves forward when the quota renews. Combined with X-Ratelimit-Remaining, it is what lets you space out requests as you approach the limit instead of stopping dead.

Once the limit is exceeded, the API responds 429 Too Many Requests and adds Retry-After:

HTTP/1.1 429 Too Many Requests
X-Ratelimit-Limit: 80
X-Ratelimit-Remaining: 0
X-Ratelimit-Reset: 1786012860
Retry-After: 37

The body follows the usual error format:

{
  "success": false,
  "status": 429,
  "message": "Too Many Requests"
}