@factorialco/api-client 3.0.0-beta.2026100136 → 3.0.0-beta.2026100138

package/dist/esm/generated/sdk.gen.js

@@ -1374,6 +1374,20 @@ export const getApi20261001ResourcesCompensationsPayrollResultsById = (options)
     url: '/api/2026-10-01/resources/compensations/payroll_results/{id}',
     ...options
 });
+/**
+ * Bulk creates a Payroll result
+ *
+ * Imports payroll result amounts for employees of a payroll run. Re-posting an (employee, concept) pair replaces its amount; concepts not included in the request are left untouched. Every employee entry must include the company's net_pay concept.
+ */
+export const postApi20261001ResourcesCompensationsPayrollResultsBulkCreate = (options) => (options?.client ?? client).post({
+    security: [{ scheme: 'bearer', type: 'http' }, { name: 'x-api-key', type: 'apiKey' }],
+    url: '/api/2026-10-01/resources/compensations/payroll_results/bulk_create',
+    ...options,
+    headers: {
+        'Content-Type': 'application/json',
+        ...options?.headers
+    }
+});
 /**
  * Reads all Payroll runs
  *
@@ -4715,6 +4729,40 @@ export const putApi20261001ResourcesPostsPostsById = (options) => (options.clien
         ...options.headers
     }
 });
+/**
+ * Creates a Materialized process
+ *
+ * Creates a Materialized process
+ */
+export const postApi20261001ResourcesProcessesMaterializedProcesses = (options) => (options?.client ?? client).post({
+    security: [{ scheme: 'bearer', type: 'http' }, { name: 'x-api-key', type: 'apiKey' }],
+    url: '/api/2026-10-01/resources/processes/materialized_processes',
+    ...options,
+    headers: {
+        'Content-Type': 'application/json',
+        ...options?.headers
+    }
+});
+/**
+ * Reads all Processes
+ *
+ * Reads all Processes
+ */
+export const getApi20261001ResourcesProcessesProcesses = (options) => (options?.client ?? client).get({
+    security: [{ scheme: 'bearer', type: 'http' }, { name: 'x-api-key', type: 'apiKey' }],
+    url: '/api/2026-10-01/resources/processes/processes',
+    ...options
+});
+/**
+ * Reads a single Process
+ *
+ * Reads a single Process
+ */
+export const getApi20261001ResourcesProcessesProcessesById = (options) => (options.client ?? client).get({
+    security: [{ scheme: 'bearer', type: 'http' }, { name: 'x-api-key', type: 'apiKey' }],
+    url: '/api/2026-10-01/resources/processes/processes/{id}',
+    ...options
+});
 /**
  * Reads all Po field values
  *
@@ -6030,7 +6078,7 @@ export const getApi20261001ResourcesTeamsMemberships = (options) => (options?.cl
 /**
  * Creates a Membership
  *
- * Assign an employee to a team, meaning create a membership.
+ * Assign an employee to a team, meaning create a membership. For companies with nested teams, two extra semantics apply. Propagation: memberships are inherited upwards, so after adding an employee to a sub-team, inherited membership rows for its ancestor teams are materialized asynchronously — rows you did not create will appear in later reads. Reuse: if the employee already has a membership row on that team (typically an inherited one), no new row is created — the employee becomes a direct member of the team, the `lead` flag is applied when you send one, and the existing row (with its existing id) is returned instead of a new resource. Omitting `lead` leaves a reused row's leadership as it was, so replaying an addition never demotes a current lead; a genuinely new row is created without it. The response is still `201` when an existing row is reused, so compare the returned `id` against what you already hold to tell the two cases apart.
  */
 export const postApi20261001ResourcesTeamsMemberships = (options) => (options?.client ?? client).post({
     security: [{ scheme: 'bearer', type: 'http' }, { name: 'x-api-key', type: 'apiKey' }],
@@ -6044,7 +6092,7 @@ export const postApi20261001ResourcesTeamsMemberships = (options) => (options?.c
 /**
  * Deletes a Membership
  *
- * Delete the membership to remove the employee from the team.
+ * Delete the membership to remove the employee from the team. For companies with nested teams what actually gets deleted depends on the kind of row: deleting a direct membership removes it, and the inherited copies it produced in the ancestor teams are cleaned up asynchronously. Deleting an INHERITED membership instead removes the employee's direct membership in EVERY sub-team that row originates from — rows with other ids, in teams you did not name — and the request is rejected altogether if you cannot manage one of those sub-teams. The inherited row you named also disappears asynchronously rather than in the request, so an immediate re-read may still return it; repeating the DELETE is safe rather than an error. Read that employee's memberships with `with_source_attribution` before deleting to see what is at stake: `direct` indicates which kind of row it is, and `source_team_ids` where the deletion would land. Both are advisory — the read and the delete resolve their answers independently, so re-read after deleting rather than assuming which branch ran.
  */
 export const deleteApi20261001ResourcesTeamsMembershipsById = (options) => (options.client ?? client).delete({
     security: [{ scheme: 'bearer', type: 'http' }, { name: 'x-api-key', type: 'apiKey' }],
@@ -6064,7 +6112,7 @@ export const getApi20261001ResourcesTeamsMembershipsById = (options) => (options
 /**
  * Updates a Membership
  *
- * Update the membership to either make the employee a lead of the team or remove them as a lead.
+ * Update the membership to either make the employee a lead of the team or remove them as a lead. For companies with nested teams, promoting an inherited membership (`lead: true`) first converts the employee into a direct member of the team (leads must be direct members), so the row becomes direct as a side effect. Demoting (`lead: false`) only removes the lead flag and keeps the membership.
  */
 export const putApi20261001ResourcesTeamsMembershipsById = (options) => (options.client ?? client).put({
     security: [{ scheme: 'bearer', type: 'http' }, { name: 'x-api-key', type: 'apiKey' }],
@@ -6075,6 +6123,20 @@ export const putApi20261001ResourcesTeamsMembershipsById = (options) => (options
         ...options.headers
     }
 });
+/**
+ * Moves a Membership
+ *
+ * Move a membership to a different team in one operation (the employee is removed from the current team and added to the destination). Requires the nested teams feature and permission to manage both teams. Only direct memberships can be moved — moving an inherited row is rejected.
+ */
+export const postApi20261001ResourcesTeamsMembershipsMove = (options) => (options?.client ?? client).post({
+    security: [{ scheme: 'bearer', type: 'http' }, { name: 'x-api-key', type: 'apiKey' }],
+    url: '/api/2026-10-01/resources/teams/memberships/move',
+    ...options,
+    headers: {
+        'Content-Type': 'application/json',
+        ...options?.headers
+    }
+});
 /**
  * Reads all Teams
  *
@@ -6088,7 +6150,7 @@ export const getApi20261001ResourcesTeamsTeams = (options) => (options?.client ?
 /**
  * Creates a Team
  *
- * Create a team with a given name
+ * Create a team with a given name. Passing `parent_team_id` creates it as a sub-team of that parent (nested teams): it requires the nested teams feature — companies without it get a validation error — plus permission to manage the parent team, and the hierarchy is capped at 4 levels.
  */
 export const postApi20261001ResourcesTeamsTeams = (options) => (options?.client ?? client).post({
     security: [{ scheme: 'bearer', type: 'http' }, { name: 'x-api-key', type: 'apiKey' }],
@@ -6102,7 +6164,7 @@ export const postApi20261001ResourcesTeamsTeams = (options) => (options?.client
 /**
  * Deletes a Team
  *
- * Delete a team
+ * Delete a team. Its memberships are deleted with it. For companies with nested teams, a team that still has sub-teams cannot be deleted: the request fails and lists them, so move them to another parent team (or to the root) first. Deletion never cascades — sub-teams are never deleted along with their parent.
  */
 export const deleteApi20261001ResourcesTeamsTeamsById = (options) => (options.client ?? client).delete({
     security: [{ scheme: 'bearer', type: 'http' }, { name: 'x-api-key', type: 'apiKey' }],
@@ -6133,6 +6195,20 @@ export const putApi20261001ResourcesTeamsTeamsById = (options) => (options.clien
         ...options.headers
     }
 });
+/**
+ * Moves a Team
+ *
+ * Move a team under a different parent team, or to the root of the hierarchy. Requires the nested teams feature — companies without it get a forbidden error — plus permission to manage the moved team and both parents involved; the hierarchy is capped at 4 levels. The team keeps its direct members; inherited memberships are re-propagated asynchronously to the new ancestors.
+ */
+export const postApi20261001ResourcesTeamsTeamsMove = (options) => (options?.client ?? client).post({
+    security: [{ scheme: 'bearer', type: 'http' }, { name: 'x-api-key', type: 'apiKey' }],
+    url: '/api/2026-10-01/resources/teams/teams/move',
+    ...options,
+    headers: {
+        'Content-Type': 'application/json',
+        ...options?.headers
+    }
+});
 /**
  * Reads all Allowances
  *
@@ -6437,6 +6513,20 @@ export const postApi20261001ResourcesTimeoffLeavesApproveAll = (options) => (opt
         ...options?.headers
     }
 });
+/**
+ * Bulk deletes a Leave
+ *
+ * Cancels several time-off leaves in one call. All or nothing — if any leave cannot be cancelled, none of them are.
+ */
+export const postApi20261001ResourcesTimeoffLeavesBulkDelete = (options) => (options?.client ?? client).post({
+    security: [{ scheme: 'bearer', type: 'http' }, { name: 'x-api-key', type: 'apiKey' }],
+    url: '/api/2026-10-01/resources/timeoff/leaves/bulk_delete',
+    ...options,
+    headers: {
+        'Content-Type': 'application/json',
+        ...options?.headers
+    }
+});
 /**
  * Rejects a Leave
  *