Documentation

HRTEQ documentation

HRTEQ is the recruitment CRM and compliance layer for DMW-licensed Philippine agencies. These guides cover the objects you work with, the stage gate that governs every deployment, document control and audit obligations, what may lawfully be charged to a worker, and the HTTP API behind the app.

Compliance is a gate, not a report. Stage requirements are entry conditions on the stage an application is moving into. An application cannot enter a stage while a required document is missing, unverified or expired. Only an Owner or System Administrator can override a blocking requirement, and the override is written to the audit trail with the unmet set attached.

Start here

Three articles cover most of what a new agency needs before its first intake.

Quickstart

Provision an agency workspace, understand the DMW-aligned defaults that are seeded for you, and take one applicant from intake to a live pipeline card.

Core concepts

The five objects that carry almost everything in HRTEQ, why the deployment lifecycle lives on the application rather than the person, and how tenant isolation is enforced.

Roles and permissions

The nine staff roles, the read-all write-by-module matrix behind them, who may move an application into which stage, and who may override a blocking requirement.

Browse by area

Get started

Provision a workspace, learn the vocabulary, and understand who can do what.

3 articles

Recruitment

Intake through deployment: applicants, job orders, the pipeline board, and the gate that governs it.

6 articles

Documents & compliance

Document control, verification, expiry, the audit trail, and Data Privacy Act obligations.

4 articles

Finance

The fee catalog, what may be charged to a worker, collections, and clearance.

1 article

Automation

Rules that assign work and chase deadlines, plus the scheduled sweeps behind them.

2 articles

Reference

The seeded stage tree and a plain-language index of every status you will meet.

2 articles

Developers

How the HTTP API authenticates and responds, and what is not available yet.

1 article

How the system fits together

Four objects carry almost everything. Getting them straight makes the rest of the docs read quickly.

An applicant is a person. They are created once and keep their own documents — passport, NBI clearance, PSA records.
A job order is demand from a principal, the overseas employer. It holds one or more positions, each with a quota.
An application is one applicant against one position. This is the object that moves through stages, holds the per-deployment documents, and carries the charges.
A stage has requirements. They are checked when an application tries to enter, and the officer who owns that stage is the one who may move it there.

Read Core concepts for the full object graph, then Stage gates for the rule engine.

Create an applicant

The API is the same one the app uses. Sign in, keep the session cookie, and echo the CSRF token on every write. The response returns the new id and the allocated applicantNo.

Terminal

# $API_URL is your deployment's API origin.
# In development that is http://localhost:4000.

curl -X POST "$API_URL/v1/applicants" \
  -H "Content-Type: application/json" \
  -H "X-CSRF-Token: $CSRF" \
  --cookie "hrteq_session=$SESSION" \
  -d '{
    "firstName": "Maria",
    "lastName": "Santos",
    "mobile": "+639171234567",
    "sourceChannel": "ONLINE_FORM",
    "dataPrivacyConsent": true
  }'

dataPrivacyConsent must be literally true, and at least one of mobile or email is required. See the API page for authentication, error codes and limits.

Every article