@factorialco/api-client 4.0.0-beta.2027010112 → 4.0.0-beta.2027010113

package/dist/cjs/generated/sdk.gen.d.ts

@@ -3394,7 +3394,7 @@ export declare const getApi20270101ResourcesTeamsMemberships: <ThrowOnError exte
 /**
  * Creates 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.
+ * 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 and the existing row (with its existing id) is returned instead of a new resource. On a reused row, `lead: true` promotes the employee, while `lead: false` or omitting `lead` leaves their leadership as it was: an addition never demotes a current lead, so use the update endpoint to demote. A genuinely new row is created with the `lead` you send, or 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 declare const postApi20270101ResourcesTeamsMemberships: <ThrowOnError extends boolean = false>(options?: Options<PostApi20270101ResourcesTeamsMembershipsData, ThrowOnError>) => RequestResult<PostApi20270101ResourcesTeamsMembershipsResponses, PostApi20270101ResourcesTeamsMembershipsErrors, ThrowOnError>;
 /**

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

@@ -6743,7 +6743,7 @@ exports.getApi20270101ResourcesTeamsMemberships = getApi20270101ResourcesTeamsMe
 /**
  * Creates 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.
+ * 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 and the existing row (with its existing id) is returned instead of a new resource. On a reused row, `lead: true` promotes the employee, while `lead: false` or omitting `lead` leaves their leadership as it was: an addition never demotes a current lead, so use the update endpoint to demote. A genuinely new row is created with the `lead` you send, or 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.
  */
 const postApi20270101ResourcesTeamsMemberships = (options) => (options?.client ?? client_gen_js_1.client).post({
     security: [{ scheme: 'bearer', type: 'http' }, { name: 'x-api-key', type: 'apiKey' }],

package/dist/esm/generated/sdk.gen.d.ts

@@ -3394,7 +3394,7 @@ export declare const getApi20270101ResourcesTeamsMemberships: <ThrowOnError exte
 /**
  * Creates 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.
+ * 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 and the existing row (with its existing id) is returned instead of a new resource. On a reused row, `lead: true` promotes the employee, while `lead: false` or omitting `lead` leaves their leadership as it was: an addition never demotes a current lead, so use the update endpoint to demote. A genuinely new row is created with the `lead` you send, or 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 declare const postApi20270101ResourcesTeamsMemberships: <ThrowOnError extends boolean = false>(options?: Options<PostApi20270101ResourcesTeamsMembershipsData, ThrowOnError>) => RequestResult<PostApi20270101ResourcesTeamsMembershipsResponses, PostApi20270101ResourcesTeamsMembershipsErrors, ThrowOnError>;
 /**

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

@@ -6221,7 +6221,7 @@ export const getApi20270101ResourcesTeamsMemberships = (options) => (options?.cl
 /**
  * Creates 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.
+ * 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 and the existing row (with its existing id) is returned instead of a new resource. On a reused row, `lead: true` promotes the employee, while `lead: false` or omitting `lead` leaves their leadership as it was: an addition never demotes a current lead, so use the update endpoint to demote. A genuinely new row is created with the `lead` you send, or 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 postApi20270101ResourcesTeamsMemberships = (options) => (options?.client ?? client).post({
     security: [{ scheme: 'bearer', type: 'http' }, { name: 'x-api-key', type: 'apiKey' }],

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@factorialco/api-client",
-  "version": "4.0.0-beta.2027010112",
+  "version": "4.0.0-beta.2027010113",
   "description": "Official TypeScript SDK for the Factorial API",
   "repository": {
     "type": "git",