Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/BladimirGS/judicial-backend/llms.txt

Use this file to discover all available pages before exploring further.

The logout endpoint terminates the user’s session in two steps: it forwards the current refreshToken cookie to the external auth service’s revocation endpoint (/api/AuthJWT/Revoke), then unconditionally clears the refreshToken cookie on the client. Even if the external revocation call fails — for example, because the auth service is temporarily unavailable — the local cookie is still cleared and the backend considers the session closed.

​
Endpoint

POST /api/auth/logout
PropertyValue
Auth requiredNo — uses the refreshToken httpOnly cookie
Request bodyNone
Content-TypeNot required

​
Request

No JSON body is needed. The endpoint reads the Cookie request header to forward the session to the external auth service. If no cookie is present, the revocation step is skipped entirely and the response is still 200 OK.

​
Response — 200 OK

The response confirms the session has been closed. Regardless of whether the external revocation succeeded or failed, the refreshToken cookie is cleared in the Set-Cookie header.
​
status
string
Always "success" on a 200 response.
​
message
string
Human-readable confirmation: "Sesión cerrada".
​
data
null
Always null for this endpoint.
The server clears the cookie by setting it to an expired value: 
Set-Cookie: refreshToken=; HttpOnly; Path=/api/auth; Max-Age=0
After this response, the refreshToken cookie is no longer present in the client’s cookie store and cannot be used to call /refresh.

​
Error Responses

This endpoint has no client-visible error responses. The backend always returns 200 OK. If the external revocation call fails — for example because the auth service is temporarily down — the controller catches the error internally, logs a warning, and continues. The refreshToken cookie is cleared regardless. From the client’s perspective, logout always succeeds.
Because external revocation errors are caught inside a try/catch in the controller, a 503 from the external auth service is never forwarded to the client. The cookie is always cleared and the response is always 200 OK. Any previously issued access_token remains valid until its exp claim expires — keep access_token lifetimes short if immediate invalidation is required.

​
Example

​
Request

curl -X POST http://localhost:4000/api/auth/logout \
  -b cookies.txt \
  -c cookies.txt
The -b cookies.txt flag sends the stored refreshToken cookie so the backend can forward it to the external revocation endpoint. The -c cookies.txt flag allows curl to persist the cleared cookie from the response.

​
Success response

{
  "status": "success",
  "message": "Sesión cerrada",
  "data": null
}
Clearing the cookie does not immediately invalidate an access_token that was already issued — it remains valid until its exp claim expires. If you need to protect against token reuse after logout, implement token blocklisting at the authorization middleware level or keep access_token lifetimes short.

Build docs developers (and LLMs) love

Get started for freeTalk to us