change_approval_status
ChatGPTApprove, 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 w…
change_approval_status
ChatGPTApprove, 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 w…
create
ChatGPTCreate 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
ChatGPTCreate 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.
describe
ChatGPTReturns 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
ChatGPTReturns 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.
destroy
ChatGPTDelete a record by id. This is irreversible from the API's perspective; call only when the user has explicitly asked for deletion.
destroy
ChatGPTDelete a record by id. This is irreversible from the API's perspective; call only when the user has explicitly asked for deletion.
find
ChatGPTList / 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
ChatGPTList / 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_one
ChatGPTGet / fetch / retrieve a single record by id (use find to list/query/search many).
find_one
ChatGPTGet / fetch / retrieve a single record by id (use find to list/query/search many).
list_resources
ChatGPTReturn 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
ChatGPTReturn 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.
project_analytics
ChatGPTAnalytics 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
ChatGPTAnalytics 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.
submit_time_entries
ChatGPTSubmit 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
ChatGPTSubmit 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.
update
ChatGPTUpdate an existing record by id. fields contains only the attributes to change.
update
ChatGPTUpdate an existing record by id. fields contains only the attributes to change.
user_analytics
ChatGPTHeads-up: response is bulky — every user object carries period-bucket arrays of tracked / planned / expected hours. For top-N / aggregate questions, project to the fields you actually need rather than reading the full payload inline. Heads-up: response is bulky — every user object carries period-bucket arrays of tracked / planned / expected hours. For top-N / aggregate questions, project to the fields you actually need rather than reading the full payload inline. Per-user tracked, planned, and expected hours bucketed by period For every user the caller is allowed to see, returns tracked time, worktime, planner data, and expected hours rolled up into period buckets (day / week / monthweek / month / year). Useful for utilisation views, planned-vs-actual dashboards, and capacity reports. Requires canAccessUsers, or limitedTeamStaffAccess on at least one team — in the latter case the response is restricted to users assigned to those teams.
user_analytics
ChatGPTHeads-up: response is bulky — every user object carries period-bucket arrays of tracked / planned / expected hours. For top-N / aggregate questions, project to the fields you actually need rather than reading the full payload inline. Heads-up: response is bulky — every user object carries period-bucket arrays of tracked / planned / expected hours. For top-N / aggregate questions, project to the fields you actually need rather than reading the full payload inline. Per-user tracked, planned, and expected hours bucketed by period For every user the caller is allowed to see, returns tracked time, worktime, planner data, and expected hours rolled up into period buckets (day / week / monthweek / month / year). Useful for utilisation views, planned-vs-actual dashboards, and capacity reports. Requires canAccessUsers, or limitedTeamStaffAccess on at least one team — in the latter case the response is restricted to users assigned to those teams.
whoami
ChatGPTCaller's user record plus session context: account settings (worktime, approval, and auto-locking rules), team memberships + capabilities, team-mates, resolved role + permissions, current absences, upcoming planner assignments, recently-touched projects. Call before any time-entry or absence write — accountSettings.timerMode decides the time-entry shape (duration+sorting vs startTime+endTime); the automatic*Locking and *GracePeriod rules say when historical writes are still allowed; team/role capability flags gate which writes are allowed at all. Shapes are projected (fields trimmed, planner allocation in hours) and not 1:1 with the CRUD models — call describe for the canonical fields. Date-windowed sections (absences, plannerAssignments) cover this week's Monday + ~18 days; recentProjects is not exhaustive. Use find for anything outside that scope.
whoami
ChatGPTCaller's user record plus session context: account settings (worktime, approval, and auto-locking rules), team memberships + capabilities, team-mates, resolved role + permissions, current absences, upcoming planner assignments, recently-touched projects. Call before any time-entry or absence write — accountSettings.timerMode decides the time-entry shape (duration+sorting vs startTime+endTime); the automatic*Locking and *GracePeriod rules say when historical writes are still allowed; team/role capability flags gate which writes are allowed at all. Shapes are projected (fields trimmed, planner allocation in hours) and not 1:1 with the CRUD models — call describe for the canonical fields. Date-windowed sections (absences, plannerAssignments) cover this week's Monday + ~18 days; recentProjects is not exhaustive. Use find for anything outside that scope.
