Nifty

Create or update people resources: member (A person inside a team workspace); userStatusTemplate (A reusable team-scoped template for member statuses — e.g., "In a meeting", "Focus time", "Out of office"). Pass {resource, operation} plus the resource's writable fields. Batch writes: bulkCreate, bulkUpdate — pass {resource, operation, items:[…], onError?}. Recovering a bulkCreate depends on whether you got a result envelope back. GOT ONE: trust it — it is index-aligned, rows marked ok are created, and you may send a NEW batch containing only the rows that never got created. NO ENVELOPE (timeout / lost response): resend the SAME items in the SAME order — that exact batch is deduplicated per row and replays what already landed instead of re-creating it. Do NOT re-split it or drop items first; that changes the dedup key and DOES create duplicates. bulkUpdate carries no dedup key, so it is safe to resend only because each item is an absolute field set — never resend one whose values are relative to the current value. Clearing a value: a field whose type includes "null" accepts an explicit JSON null to clear it (for an FK, to unlink it). Omitting a key leaves that field UNCHANGED — omission and null are different requests, so send only the keys you mean to change.

Read (list / get / search) people resources: member (A person inside a team workspace); userStatusTemplate (A reusable team-scoped template for member statuses — e.g., "In a meeting", "Focus time", "Out of office"). Pass {resource, operation} plus the operation's args.

Delete planning resources: form (A team-scoped form (survey / intake / check-in) whose structure is a set of ordered fields, each with a type, a label, optional multiple-choice options, and optional conditional-logic rules); goal (A team objective with tracked progress (full CRUD)); goalGroup (A team-scoped grouping for organizing related goals (e.g., "Q2 OKRs", "Engineering initiatives")); list (A project-scoped task container); portfolio (A team-scoped grouping of projects); project (A top-level container in the Nifty workspace); projectFolder (A named grouping of projects inside a portfolio); status (A project-scoped status column for tasks (Kanban column, list stage)). Pass {resource, operation: "delete", id}. Batch delete: bulkDelete — pass {resource, operation: "bulkDelete", ids:[…], onError?}. Bulk deletes are NOT idempotent-safe on retry: deleting an already-deleted row reports resource_not_found, not success. If the response is lost, re-query the ids to see what actually remains and delete only those — do not blind-retry the batch, and do not read a resource_not_found on a lost-response retry as "the delete failed".

Create or update planning resources: form (A team-scoped form (survey / intake / check-in) whose structure is a set of ordered fields, each with a type, a label, optional multiple-choice options, and optional conditional-logic rules); goal (A team objective with tracked progress (full CRUD)); goalGroup (A team-scoped grouping for organizing related goals (e.g., "Q2 OKRs", "Engineering initiatives")); list (A project-scoped task container); portfolio (A team-scoped grouping of projects); project (A top-level container in the Nifty workspace); projectFolder (A named grouping of projects inside a portfolio); status (A project-scoped status column for tasks (Kanban column, list stage)). Pass {resource, operation} plus the resource's writable fields. Also links/unlinks relations via addAssignees, addGoals, addHiddenFor, addMembers, removeAssignees, removeGoals, removeHiddenFor, removeMembers — pass {resource, operation, id, ids}. Batch writes: bulkCreate, bulkUpdate — pass {resource, operation, items:[…], onError?}. Recovering a bulkCreate depends on whether you got a result envelope back. GOT ONE: trust it — it is index-aligned, rows marked ok are created, and you may send a NEW batch containing only the rows that never got created. NO ENVELOPE (timeout / lost response): resend the SAME items in the SAME order — that exact batch is deduplicated per row and replays what already landed instead of re-creating it. Do NOT re-split it or drop items first; that changes the dedup key and DOES create duplicates. bulkUpdate carries no dedup key, so it is safe to resend only because each item is an absolute field set — never resend one whose values are relative to the current value. Clearing a value: a field whose type includes "null" accepts an explicit JSON null to clear it (for an FK, to unlink it). Omitting a key leaves that field UNCHANGED — omission and null are different requests, so send only the keys you mean to change. Add a list to an existing project for new work; create a whole project only for a genuinely new initiative. A list groups tasks (its Roadmap visibility is automatic); a status is a task's lifecycle stage; a goal is a cross-project, org-level objective (not project-level date grouping — use a list for that). Configure what you create to the user's stated purpose rather than taking kitchen-sink defaults: on project create pass only the `modules` that fit — OMITTING them enables ALL 8 feature tabs, which clutters a focused project (content calendar → [tasks, calendar, files]; bug tracker → [tasks]; knowledge base → [documents, files]). A lean setup the user can extend beats a cluttered one.

Read (list / get / search) planning resources: form (A team-scoped form (survey / intake / check-in) whose structure is a set of ordered fields, each with a type, a label, optional multiple-choice options, and optional conditional-logic rules); goal (A team objective with tracked progress (full CRUD)); goalGroup (A team-scoped grouping for organizing related goals (e.g., "Q2 OKRs", "Engineering initiatives")); list (A project-scoped task container); portfolio (A team-scoped grouping of projects); project (A top-level container in the Nifty workspace); projectFolder (A named grouping of projects inside a portfolio); status (A project-scoped status column for tasks (Kanban column, list stage)). Pass {resource, operation} plus the operation's args. For project-scoped resources here (list, status): "search" REQUIRES `projectId` (no workspace-wide fallback — omitting it errors `project_not_specified`); "list" does NOT require it (omitting it falls back to a workspace-wide scan).

Delete reporting resources: reportChart (A team-scoped saved reporting chart that aggregates task data (live, events, or historical) across one or more projects); timeEntry (A user's time-tracked interval on a task (and optionally a project)). Pass {resource, operation: "delete", id}. Batch delete: bulkDelete — pass {resource, operation: "bulkDelete", ids:[…], onError?}. Bulk deletes are NOT idempotent-safe on retry: deleting an already-deleted row reports resource_not_found, not success. If the response is lost, re-query the ids to see what actually remains and delete only those — do not blind-retry the batch, and do not read a resource_not_found on a lost-response retry as "the delete failed".

Create or update reporting resources: reportChart (A team-scoped saved reporting chart that aggregates task data (live, events, or historical) across one or more projects); timeEntry (A user's time-tracked interval on a task (and optionally a project)). Pass {resource, operation} plus the resource's writable fields. Also links/unlinks relations via addProjects, removeProjects — pass {resource, operation, id, ids}. Batch writes: bulkCreate, bulkUpdate — pass {resource, operation, items:[…], onError?}. Recovering a bulkCreate depends on whether you got a result envelope back. GOT ONE: trust it — it is index-aligned, rows marked ok are created, and you may send a NEW batch containing only the rows that never got created. NO ENVELOPE (timeout / lost response): resend the SAME items in the SAME order — that exact batch is deduplicated per row and replays what already landed instead of re-creating it. Do NOT re-split it or drop items first; that changes the dedup key and DOES create duplicates. bulkUpdate carries no dedup key, so it is safe to resend only because each item is an absolute field set — never resend one whose values are relative to the current value. Clearing a value: a field whose type includes "null" accepts an explicit JSON null to clear it (for an FK, to unlink it). Omitting a key leaves that field UNCHANGED — omission and null are different requests, so send only the keys you mean to change.

Read (list / get / search) reporting resources: projectActivity (A read-only, append-only per-project ACTIVITY FEED row: WHO triggered WHICH domain event in a project); reportChart (A team-scoped saved reporting chart that aggregates task data (live, events, or historical) across one or more projects); timeEntry (A user's time-tracked interval on a task (and optionally a project)). Pass {resource, operation} plus the operation's args. For project-scoped resources here (projectActivity): "search" REQUIRES `projectId` (no workspace-wide fallback — omitting it errors `project_not_specified`); "list" does NOT require it (omitting it falls back to a workspace-wide scan).

Delete tasks resources: checklist (A named, ordered container of checklist items on a task); checklistItem (A single completable line inside a checklist); reminder (A scheduled reminder anchored to a task); task (A unit of work in a project); tasksLayout (A saved task-board VIEW/LAYOUT for a user (per-user, optionally per-project): the board type + a jsonb `config` (filters, grouping, sort, hidden columns, calendar range, etc.)). Pass {resource, operation: "delete", id}. Batch delete: bulkDelete — pass {resource, operation: "bulkDelete", ids:[…], onError?}. Bulk deletes are NOT idempotent-safe on retry: deleting an already-deleted row reports resource_not_found, not success. If the response is lost, re-query the ids to see what actually remains and delete only those — do not blind-retry the batch, and do not read a resource_not_found on a lost-response retry as "the delete failed".

Create or update tasks resources: checklist (A named, ordered container of checklist items on a task); checklistItem (A single completable line inside a checklist); reminder (A scheduled reminder anchored to a task); task (A unit of work in a project); tasksLayout (A saved task-board VIEW/LAYOUT for a user (per-user, optionally per-project): the board type + a jsonb `config` (filters, grouping, sort, hidden columns, calendar range, etc.)). Pass {resource, operation} plus the resource's writable fields. Also links/unlinks relations via addAssignees, addConnectedTasks, addHiddenFor, addLabels, addSubscribers, removeAssignees, removeConnectedTasks, removeHiddenFor, removeLabels, removeSubscribers — pass {resource, operation, id, ids}. Batch writes: bulkCreate, bulkUpdate — pass {resource, operation, items:[…], onError?}. Recovering a bulkCreate depends on whether you got a result envelope back. GOT ONE: trust it — it is index-aligned, rows marked ok are created, and you may send a NEW batch containing only the rows that never got created. NO ENVELOPE (timeout / lost response): resend the SAME items in the SAME order — that exact batch is deduplicated per row and replays what already landed instead of re-creating it. Do NOT re-split it or drop items first; that changes the dedup key and DOES create duplicates. bulkUpdate carries no dedup key, so it is safe to resend only because each item is an absolute field set — never resend one whose values are relative to the current value. Clearing a value: a field whose type includes "null" accepts an explicit JSON null to clear it (for an FK, to unlink it). Omitting a key leaves that field UNCHANGED — omission and null are different requests, so send only the keys you mean to change. Structure work with native fields, not prose: a tick-off step → a checklistItem; a step someone owns/schedules (its own assignee, due date, or status) → a subtask (a task with parentTaskId); a typed attribute recorded across tasks (budget / priority / a date) → a customField. Categorize a task by status (lifecycle stage), label (free-form, multiple per task), or customField (typed, one value per field). HARD RULE: before writing a bulleted or numbered list of actionable items inside a description, STOP — each line is a subtask or checklistItem per the mapping above; a work-list buried in prose is an anti-pattern (a description holds rationale/context/ evidence only). Mirror a source doc's hierarchy: a phase/milestone → a list or task, its steps → subtasks, a step's checks → checklistItems. "Lean, not kitchen-sink" governs FEATURES (modules, statuses, custom fields, views), NOT decomposition — splitting real work into subtasks/checklist is expected structure, not clutter.

Read (list / get / search) tasks resources: checklist (A named, ordered container of checklist items on a task); checklistItem (A single completable line inside a checklist); reminder (A scheduled reminder anchored to a task); task (A unit of work in a project); tasksLayout (A saved task-board VIEW/LAYOUT for a user (per-user, optionally per-project): the board type + a jsonb `config` (filters, grouping, sort, hidden columns, calendar range, etc.)). Pass {resource, operation} plus the operation's args. For project-scoped resources here (task): "search" REQUIRES `projectId` (no workspace-wide fallback — omitting it errors `project_not_specified`); "list" does NOT require it (omitting it falls back to a workspace-wide scan).