Session-based access
The account API uses Laravel Sanctum sessions. Requests are scoped to the signed-in account; monitor IDs do not grant access to someone else’s data.
FOR THE CURIOUS & THE BUILDERS
A closer look under the hood.
Understand how the workspace connects its sources, snapshots, and detections. A practical reference for the current application.
Two capture methods
Public checks read supported server HTML or plain text. Browser checks use a user-reviewed capture of rendered text and links. Both feed the same comparison workflow.
Application reference
These are endpoints used by the DoitDesk application. The web interface uses session cookies. API clients can use the backend?s bearer-token login flow; both flows retain account ownership checks and workspace limits.
AUTHENTICATION
Keep the session and CSRF flow together.
- Initialize the session. The frontend first requests
/sanctum/csrf-cookiefrom the configured account-server origin with credentials included. - Authenticate through the account flow. Login and registration use the session. Personal accounts must verify their email before workspace access.
- Include credentials on API requests. Mutations send the decoded XSRF cookie as
X-XSRF-TOKEN, plus JSON and an appropriate Accept header. Cross-origin calls require the configured CORS and cookie-domain settings. - Handle errors as part of the flow. An expired session requires sign-in. Validation errors, ownership checks, cooldowns, and guest quotas still apply to requests made outside the interface.
For a non-browser API client: send an existing account?s email and password to POST /api/login. The response includes a bearer token. Use Authorization: Bearer <token> on account API calls, and POST /api/logout to revoke that token. This flow does not use the browser?s CSRF-cookie sequence. Workspace access still requires a verified personal account.
WORKSPACE ENDPOINTS
The pieces behind the interface.
Paths below are relative to the configured account API origin.
| Method | Path | Purpose |
|---|---|---|
| POST | /api/login | Authenticate an existing account and receive a personal access token. |
| POST | /api/logout | Revoke the current bearer token used by an API client. |
| GET | /api/workspace | Read the signed-in workspace, monitors, profile, and recent detections. |
| GET | /api/monitors | List monitors owned by the current account. |
| POST | /api/monitors | Create a monitor with its source, type, and filtering settings. |
| PATCH | /api/monitors/{id} | Update an owned monitor, including its active status and checking method. |
| POST | /api/monitors/{id}/checks | Request a manual public-page check. |
| POST | /api/monitors/{id}/browser-checks | Save a reviewed visible-text capture for an owned browser-mode monitor. |
| GET | /api/monitors/{id}/runs | Read up to twenty recent check runs and their retained snapshots. |
| GET | /api/detections | Read recent detections from the account’s own monitors. |
A MONITOR AT A GLANCE
Start with the source and the intent.
{
"name": "Engineering careers",
"url": "https://example.com/careers",
"type": "JOBS",
"checkMode": "server",
"keywords": [
"React",
"Remote"
],
"selector": "main",
"active": true,
"email": false
}Settings that shape the comparison
Supported types are WEBSITE_CHANGE, JOBS, TENDERS, and COMPETITOR. Choose server or browser as the check mode.
Changing URL, selector, type, keywords, or checking method resets the baseline. Snapshots, run history, and detection IDs are produced by the checking workflow, rather than supplied as monitor settings.
Understand matchingLimits are part of the contract.
A workspace supports up to five active monitors and fifty monitors in total. Each monitor has a one-minute cooldown. Guest access has a three-check daily quota. Service-level rate and concurrency limits may also apply. Checks remain manual; notification preferences do not trigger email delivery.
Troubleshoot a checkA LITTLE LESS CHECKING
Put your first page on the radar.
Start with a guest workspace, or follow a guide at your own pace.