Aerion

Approve, reject, or change submission status of time entries — and lock/unlock project days. Three input shapes; variant is chosen by which fields you supply: • Single entry — `timeEntryId` + `validationStatus`. Granular state change for one entry, with optional field patches, break patches, and rejection/resubmission email. • Bulk WORK across dates — `dates` (≤7) + `projectId` and/or `userId` + `teStatus` and/or `dayStatus`. Approves submitted entries and/or locks days. Locking a day blocks further WORK entry creation on that (project, date) by any user — independent of whether the date is past, present, or future, and the day need not have any entries. Locking only happens when `projectId` is set *without* `userId` (scoping by user keeps the day open to others). • Bulk WORKTIME — `userId` + `startDate` + `endDate` + `status`. WORKTIME-only, range ≤7 days. ▸ POST /v1/approval/change-status Approve, reject, or re-submit a single time entry Changes one time entry's `validationStatus` and, optionally, patches its fields and sibling break entries in the same call. If the entry's `ProjectDay` is `APPROVED` and the new status is not `APPROVED`, the **ProjectDay is automatically unlocked** (set to `NOTAPPROVED` with `approvedBy` / `approvedOn` cleared) — only a PM of the project may trigger this. Permissions: an owner may submit their own entry; PMs of the entry's project may approve/reject WORK entries; users with `canApproveTeamWorktime` over the entry owner's team may approve/reject WORKTIME and BREAK entries. Running entries are rejected. Rejection (`sendRejectionEmail`) and re-submission (`sendResubmissionEmail`) notifications are sent asynchronously and do not block the response. ▸ POST /v1/approval/bulk-approve Approve / unapprove time entries and lock / unlock project days across up to seven days Performs two related actions in one call. **This is the canonical endpoint for approving or unapproving project days** — direct CRUD on `/v1/project-days` is not supported. - **Approving time entries** (retrospective): sets `validationStatus: APPROVED` on existing WORK entries that have already been submitted. - **Locking project days** (write-blocking): an APPROVED ProjectDay closes that (project, date) to *all* further WORK entry creation by *any* user until it is unlocked — this is the gate, not a side effect of approving entries. ProjectDay records may be locked on dates with **zero existing time entries**; this is the right way to close any period (past, present, or future) to new tracking without affecting any existing work. Invariant: an APPROVED ProjectDay means every WORK entry on that day is also APPROVED. There is no separate "approve the entries first, then approve the day" path — this endpoint is that path. Passing `dayStatus: APPROVED` together with `teStatus: APPROVED` both approves the day's submitted entries and locks the day in one shot. (Days with zero entries trivially satisfy the invariant and are still locked.) Two parameter modes: - **Single-status (`validationStatus`)**: sets `dayStatus` to `validationStatus`; `teStatus` defaults to `APPROVED` when approving, `SUBMITTED` otherwise. - **Split (`teStatus` + `dayStatus`)**: control the two independently within the invariant above. To lock a day, pass both as `APPROVED`. Constraints: `dates` capped at 7. At least one of `projectId` and `userId` must be set. ProjectDay locking only happens when `projectId` is set without `userId` (scoping by a single user does not lock the day, since other users may still need to track to it). Operates on WORK entries only. Permissions are checked per project: only PMs of a project may approve / unlock that project's days. Per-day and per-TE errors are collected into `dayErrors` rather than aborting the batch. ▸ POST /v1/approval/bulk-approve-worktime Bulk-change validationStatus on a user's worktime entries across a date range Bulk-updates `validationStatus` on a single user's WORKTIME entries across a date range of up to seven days. Only entries already past `NOTSUBMITTED` are affected — submitted, approved, and rejected worktime can be moved between those states; not-yet-submitted worktime is ignored. When the new status is `APPROVED`, `approvedBy` and `approvedOn` are stamped; otherwise both are cleared. Permissions: `canManageUsers` for any user, or `canApproveTeamWorktime` covering a team the target user belongs to. Does not touch WORK or BREAK entries and does not affect ProjectDay records. Per-entry failures are collected into `errors` rather than aborting the batch.

change_approval_status

Create a new record. `fields` is an object of attribute=value pairs. Call describe first to see required vs optional fields and read-only fields to omit.

create

Delete a record by id. This is irreversible from the API's perspective; call only when the user has explicitly asked for deletion.

destroy

Returns the resource schema: attributes (names + types + descriptions), the `filterable` subset (valid in `where`), and `methodNotes` (per-method constraints like immutable-after-creation — read before mutating). Associations appear as integer ID attributes naming the related model. Call before any find / create / update if you don't know the field shape.

describe

List / query / search / filter records for a resource (use `find_one` if you already have a single id). `where` is a Waterline criteria object combining equality, operator, and association filters. The resource's `filterable` array (from `describe`) lists valid keys. Three worked examples covering the common patterns: User-actionable time entries (combines AND, OR, range, null literal): { "user": "3", "trackingType": "WORK", "or": [ { "validationStatus": "REJECTED" }, { "validationStatus": "NOTSUBMITTED", "validation": null, "day": { "<=": "2026-04-28", ">": "2025-01-01" } } ] } Time entries by task / user / project's client (arrays, dot-notation, range): { "trackingType": "WORK", "day": { ">=": "2025-01-01", "<=": "2025-12-31" }, "task": ["96719"], "user": ["3"], "project.client": ["2"] } PlannerAssignments overlapping a date window (overlap pattern, strict inequalities): { "or": [ { "startDate": { ">=": "2026-04-26T22:00:00.000Z", "<=": "2026-05-03T21:59:59.999Z" } }, { "endDate": { ">=": "2026-04-26T22:00:00.000Z", "<=": "2026-05-03T21:59:59.999Z" } }, { "startDate": { "<": "2026-04-26T22:00:00.000Z" }, "endDate": { ">": "2026-05-03T21:59:59.999Z" } } ] } Syntax (stock Waterline criteria — see https://sailsjs.com/documentation/concepts/models-and-orm/query-language): - AND is implicit when keys are siblings in the same object. - OR via `or: [...]` — array of clause-objects, each clause is itself an AND of its keys. `or` may be nested inside another `or` clause if needed. - `and: [...]` also works for explicit AND siblings, though usually unnecessary. - `not:` is not supported. Negate via `!=` on a field, or rewrite as an OR of wanted cases. - Operators are quoted-string keys on a per-field object, e.g. { day: { '>=': '2026-01-01', '<=': '2026-01-31' } }. Stock Waterline ops: '<', '<=', '>', '>=', '!=', 'nin', 'contains', 'startsWith', 'endsWith', 'like'. - Array values are IN-semantic shorthand: { task: ['96719'] } means task in [96719]. A single value or single-element array both work for equality. - `null` literal matches records where the field is null. - Cross-association dot-notation (e.g. `project.client`) filters by the related model's field. - Date format depends on the field type — describe(resource) tells you. Pure date fields use 'YYYY-MM-DD'; datetime fields use full ISO 8601 with timezone, e.g. '2026-05-03T21:59:59.999Z'.

find

Get / fetch / retrieve a single record by id (use find to list/query/search many).

find_one

Return the list of available Aerion resources (e.g. 'users', 'time-entries', 'projects'). Call this first if you don't already know what resources exist. Each entry shows the supported methods and, where present, `aliases` — other words a user might use for that resource (e.g. 'skills' maps to 'tags'). Call describe(resource) to see fields.

list_resources

Analytics for projects. Without `id`: per-project rollups across readable projects (filterable, coarser). With `id`: deep analytics for one project — breakdowns by user / task / reference / team. Different params per variant; pick one set. Heads-up: bulky response — each project carries a monthly histogram going back years. For top-N / aggregate questions, project to the fields you need (e.g. id, name, hours.tracked) instead of reading the full payload. ▸ GET /v1/analytics/projects/{id} Get analytics for a single project Deep analytics for one project: same hours/amount/histogram fields as the multi-project variant, plus per-user actuals (tracked hours, costs) and breakdowns by task, workset, reference, and team that the multi variant does not include. Single object response — not an array. Histogram can be multi-year; project to the fields you need if all you want is top-line numbers. Returns budgets, time entries, expenses, invoices, planned invoices, costs, and a monthly histogram for one project, plus breakdowns by user, task, workset, reference, and team. Invoice and planned-invoice payloads include an `internal` / `external` split keyed by `isInternal`. The caller must be able to read the project (404 otherwise) and either manage all projects, be a project manager on it, or have `canAccessOwnProjects` (400 otherwise). ▸ GET /v1/analytics/projects List analytics across projects Returns one record per project the caller can read, each with summary hours/amount/cost figures and a multi-year monthly histogram. Bulky — for top-N or aggregate questions, project to the fields you need (e.g. id, hours.spent) rather than reading the full payload inline. Filter via `project` (specific IDs) or `start_date`/`end_date` (date window). For deep single-project analytics with per-user / per-task / per-workset / per-reference / per-team breakdowns, use the `/v1/analytics/projects/{id}` variant — its response shape is different (single object, more breakdowns, full per-user actuals). Returns per-project roll-ups (hours, amount, costs, monthly histogram, invoices, planned invoices, planner data) for every project the caller can read. Invoice and planned-invoice payloads include an `internal` / `external` split keyed by `isInternal`. Filterable by project IDs and an optional date range. Requires `canAccessOwnProjects`, project-manager status on the targeted projects, or admin.

project_analytics

Submit the caller's own time entries for a single day Advances the caller's unsubmitted and rejected project time for the given day to submitted; running entries are stopped first. If work time tracking is active on the account and no submitted or approved work time entry exists for the day, one is created from the caller's default start and end times (or a zero-duration record on a non-working day) and submitted. This endpoint only acts on the invoking user's own time entries.

submit_time_entries

Update an existing record by id. `fields` contains only the attributes to change.

update