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. 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, 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, 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-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 `NOTSUBMITTED` and `REJECTED` WORK time entries on the given day to `SUBMITTED`. Running entries are stopped first. If worktime tracking is active on the account and no `SUBMITTED`/`APPROVED` WORKTIME entry exists for the day, one is created from the user's default start/end (or a zero-duration record on a non-working day) and submitted. Scoped to the caller — there is no way to submit on behalf of another user.

submit_time_entries

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

update