CMS Admin

Authentication

You'll need to authenticate your requests to access any of the endpoints in the CMS Admin API. In this guide, we'll look at how authentication works using Laravel Sanctum's session-based CSRF flow, plus the two-factor authentication and session-management features layered on top of it.

Session-based authentication

The CMS Admin API uses Laravel Sanctum for SPA (Single Page Application) authentication. This uses session cookies and CSRF tokens rather than bearer API tokens — although a named personal access token is also minted behind the scenes on every login (see Sessions below).

Step 1: Get CSRF cookie

First, make a request to get the CSRF token cookie:

Get CSRF cookie

curl -X GET https://your-domain.com/sanctum/csrf-cookie \
  -H "Accept: application/json" \
  --cookie-jar cookies.txt

Step 2: Login

Use the CSRF token to authenticate with email and password:

Login request

curl -X POST https://your-domain.com/login \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "X-XSRF-TOKEN: {xsrf_token}" \
  --cookie cookies.txt \
  --cookie-jar cookies.txt \
  -d '{
    "email": "admin@example.com",
    "password": "password"
  }'

Step 3: Make authenticated requests

After login, include the session cookie in all subsequent requests:

Authenticated request

curl https://your-domain.com/api/case-records \
  -H "Accept: application/json" \
  -H "X-XSRF-TOKEN: {xsrf_token}" \
  --cookie cookies.txt

The session cookie (named cms_admin_session by default, derived from APP_NAME) is automatically managed when using a browser-based SPA client. For server-to-server integrations, you need to manage cookies and CSRF tokens manually.

Origin-based access control

Login is additionally gated by the request origin. The backend checks the Origin/Referer header against an allow-list and rejects logins for role types that aren't permitted from that origin — for example, the public cms-portal.revlv.com frontend (Counsel and public User accounts) is not allowed to authenticate staff accounts, and the internal cms-admin.revlv.com staff frontend excludes public accounts. If you're integrating a new client, make sure its origin is registered and permitted for the account types it needs to log in.

Rate limiting

Login attempts are throttled to 3 attempts per hour, keyed by the lowercased email address plus client IP. Exceeding the limit returns 429 Too Many Requests with a Retry-After header, and repeated failures trigger a security notification email.

Two-factor authentication

Two-factor authentication is available via Fortify and requires password confirmation to enable. When 2FA is enabled for a user, POST /login returns {"two_factor": true} instead of completing the session — the client must then complete the challenge:

POST
/two-factor-challenge
curl -X POST https://your-domain.com/two-factor-challenge \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "X-XSRF-TOKEN: {xsrf_token}" \
  --cookie cookies.txt \
  --cookie-jar cookies.txt \
  -d '{"code": "123456"}'

A recovery_code may be submitted instead of code if the authenticator device is unavailable. Once 2FA is set up, standard Fortify endpoints manage it: POST /user/two-factor-authentication (enable), POST /user/confirmed-two-factor-authentication (confirm with a code), DELETE /user/two-factor-authentication (disable), and GET /user/two-factor-qr-code / GET /user/two-factor-recovery-codes.

Registration and email verification

New Counsel/public-user accounts are not created through Fortify's built-in registration — they go through bespoke endpoints:

  • Name
    POST /check-email
    Description

    Checks whether an email address is already registered. Throttled to 30 requests/minute.

  • Name
    POST /register
    Description

    Self-registration for bar members and public users. Requires is_bar_member, first_name, last_name, birthdate, sex, email, contact_number (format +639XXXXXXXXX). If is_bar_member is yes, also requires bar_type, bar_year, roll_number (unique), bar_signed_at, and three uploaded images: latest_unretouched_photo, government_id_front, government_id_back.

  • Name
    POST /set-password
    Description

    Sets the account password via a signed URL (sent by email after registration) and marks the account verified.

  • Name
    POST /email_verify
    Description

    Verifies the account's email address via a signed URL.

  • Name
    POST /resend_verification
    Description

    Resends the verification/set-password email.

Sessions

Every successful login mints a named Sanctum personal access token (session-{sessionId}) alongside the cookie session, recording the IP address and user agent. These are exposed as manageable "sessions" so a user can review and revoke devices:

  • Name
    GET /api/profile/sessions
    Type
    GET
    Description

    List all active sessions/tokens for the authenticated user.

  • Name
    DELETE /api/profile/sessions
    Type
    DELETE
    Description

    Revoke a specific session by token id.

  • Name
    POST /api/profile/sessions/terminate-others
    Type
    POST
    Description

    Revoke every session except the one making the current request.

Super Admins can additionally list every user's active sessions across the system via GET /api/admin/all-user-sessions.

OAuth (scportal)

A separate stateless OAuth flow exists for the scportal provider: GET /auth/scportal/redirect starts the flow, and GET /auth/scportal/callback completes it, creating or matching a User by email and logging them in. No other OAuth providers are enabled.

Roles

Users are assigned one or more Spatie roles that determine their access level via role: and permission: route middleware:

  • Name
    Super Admin
    Type
    role
    Description

    Full access. Most Super Admin gates check the role name directly rather than a specific permission.

  • Name
    Office of the Court Clerk
    Type
    role
    Description

    OCC staff — case raffling, branch/status/defendant updates, case filing, evidence, and case history access.

  • Name
    Branch of the Court Clerk
    Type
    role
    Description

    BCC staff working within a specific branch — hearings, activities, minutes of the hearing, TSN, sheriff's reports, evidence, calendar, articles, and reports.

  • Name
    BCC Staff
    Type
    role
    Description

    Narrower BCC access focused on case filing and case details/history.

  • Name
    BCC Evidence
    Type
    role
    Description

    BCC access scoped to evidence management.

  • Name
    Judge
    Type
    role
    Description

    Judicial access to branch-scoped case records, collaborators, and related cases.

  • Name
    Stenographer
    Type
    role
    Description

    Read access to case details/activities/history plus stenographic-note (TSN) responsibilities.

  • Name
    Sheriff
    Type
    role
    Description

    Read access to case details/activities/history plus sheriff's-report responsibilities.

  • Name
    Counsel
    Type
    role
    Description

    External counsel of record — evidence and witness submission on their own cases.

  • Name
    User
    Type
    role
    Description

    Public/self-registered account with the most limited access.

  • Name
    Dashboard User
    Type
    role
    Description

    Read-only access to calendars, articles, and reports.

See Roles and Permissions for the full CRUD API over these.

Logout

To end a session, send a POST request to the logout endpoint:

Logout

curl -X POST https://your-domain.com/logout \
  -H "Accept: application/json" \
  -H "X-XSRF-TOKEN: {xsrf_token}" \
  --cookie cookies.txt

A JSON request receives a 204 No Content response.

Was this page helpful?