@greensecurity/javascript-sdk 0.46.0-beta.4 → 0.46.0-beta.6

package/dist/commonjs/sdk/systems.js

@@ -12,11 +12,11 @@ class Systems extends sdks_js_1.ClientSDK {
      * List systems
      *
      * @remarks
-     * List or search systems.
+     * Lists or searches systems.
      *
-     * **Permissions.** Requires the `systems.view` permission. `facilities.view` is additionally needed for the `system.facilities` expansion scope to be applied.
+     * **Permissions.** Requires the `systems.view` permission. The `system.facilities` expansion scope also requires `facilities.view`.
      *
-     * Available `expand` scopes are:
+     * The `expand` parameter accepts the following scopes:
      *
      * - `system.facilities`
      * - `system.location`
@@ -31,7 +31,7 @@ class Systems extends sdks_js_1.ClientSDK {
      * - `system.pricing_model`
      * - `system.initiate_visit_request_requirements`
      *
-     * Unrecognised values are ignored. Each scope is also accepted without the `system.` prefix (`location`, `gpo`, and so on) for backwards compatibility. Expansion is dropped for callers without facilities-view permission.
+     * The endpoint ignores unrecognized values. Each scope is also accepted without the `system.` prefix (`location`, `gpo`, and so on) for backwards compatibility. The endpoint drops expansion for callers without facilities-view permission.
      */
     async listSystems(request, options) {
         return (0, operations_js_1.unwrapResultIterator)((0, systemsListSystems_js_1.systemsListSystems)(this, request, options));

package/dist/commonjs/sdk/users.d.ts

@@ -11,15 +11,15 @@ export declare class Users extends ClientSDK {
      * By default the response returns a compact profile (id, name, email,
      * phone, timezone, user type, and a handful of confirmation flags).
      *
-     * **Permissions.** Requires a valid token only - a caller may always read their own record.
+     * **Permissions.** Requires a valid token only: a caller can always read their own record.
      *
      * Supported `expand` values:
-     * - `user` — return the full user record, including all profile fields stored against the user (sensitive columns such as passwords, MFA codes, and payment-provider IDs are always omitted)
-     * - `user.email_preferences` — include the user's `email_preferences` block (notification recipients, weekly email flags, and — for company managers — `receive_vendor_emails`)
-     * - `user.payment_profile` — include the user's `payment_profile` block (card type, last four digits, validity flags) when expanded; if no payment profile is associated with the user, the response returns `payment_profile: null`
-     * - `company.location`, `company.vendor_type_restrictions`, `company.vendor_fields` — only valid for Company Manager users; embed extra fields on the user's company
+     * - `user`: return the full user record, including all profile fields stored against the user (sensitive columns such as passwords, MFA codes, and payment-provider IDs are always omitted)
+     * - `user.email_preferences`: include the user's `email_preferences` block (notification recipients, weekly email flags, and, for company managers, `receive_vendor_emails`)
+     * - `user.payment_profile`: include the user's `payment_profile` block (card type, last four digits, validity flags) when expanded; if the user has no payment profile, the response returns `payment_profile: null`
+     * - `company.location`, `company.vendor_type_restrictions`, `company.vendor_fields`: only valid for Company Manager users; embed extra fields on the user's company
      *
-     * Multiple values can be combined with commas, e.g.
+     * Combine multiple values with commas, for example,
      * `?expand=user.email_preferences,company.location`.
      */
     getCurrentUser(request: operations.GetCurrentUserRequest, options?: RequestOptions): Promise<components.User>;
@@ -33,11 +33,11 @@ export declare class Users extends ClientSDK {
      * By default the response returns a compact profile (id, name, email,
      * phone, timezone, user type, and a handful of confirmation flags).
      *
-     * **Permissions.** Requires any of `users.view`, `vendors.view`, `contacts.view`, `inventory_managers.view` or `company_managers.view`. Which one applies depends on the target user's type; callers may always read their own record.
+     * **Permissions.** Requires any of `users.view`, `vendors.view`, `contacts.view`, `inventory_managers.view` or `company_managers.view`. Which one applies depends on the target user's type; callers can always read their own record.
      *
      * Supported `expand` values:
-     * - `user` — return the full user record (sensitive columns such as passwords and payment-provider IDs are always omitted)
-     * - `user.email_preferences` — include the user's `email_preferences` block (notification recipients, weekly email flags, and — for company managers — `receive_vendor_emails`)
+     * - `user`: return the full user record (sensitive columns such as passwords and payment-provider IDs are always omitted)
+     * - `user.email_preferences`: include the user's `email_preferences` block (notification recipients, weekly email flags, and, for company managers, `receive_vendor_emails`)
      */
     getUserById(request: operations.GetUserByIdRequest, options?: RequestOptions): Promise<components.User>;
     /**
@@ -48,13 +48,13 @@ export declare class Users extends ClientSDK {
      * preferences of a user. Pass `me` as `{id}` to update the authenticated
      * user's own profile, or a positive integer user ID otherwise.
      *
-     * Only submitted fields are applied — unrecognised fields are silently ignored.
+     * The API applies only submitted fields and silently ignores unrecognized fields.
      * Changing `email` automatically resets `bounced_email` to `false`.
      *
      * Submitting `zip`, `state`, or `country` cross-checks the postal code against the
-     * resulting state/country (using the existing value for any of the three left out
+     * resulting state or country (using the existing value for any of the three left out
      * of the request). A code that is not shaped like a real postal code, or that
-     * provably belongs to a different state, is rejected with `422` naming the correct
+     * provably belongs to a different state, gets a `422` response naming the correct
      * state.
      *
      * Each subkey of `email_preferences` is independently optional; sending
@@ -75,71 +75,71 @@ export declare class Users extends ClientSDK {
      * Logs user into the system
      *
      * @remarks
-     * This endpoint allows a user to authenticate themselves and retrieve a permanent token for access.
+     * Authenticates a user and returns a permanent token for access.
      *
-     * Permanent tokens should only ever be stored in an encrypted storage because they represent a fully logged in user.
+     * Store permanent tokens only in encrypted storage because they represent a fully signed-in user.
      *
-     * Users may log in with `email/password`, `SAML`, `magic link` or `mfa`. The application should handle all of the above as equally valid login methods.
+     * Users can sign in with `email/password`, `SAML`, `magic link` or `mfa`. The application should handle all of these as equally valid sign-in methods.
      *
-     * The most common way to authenticate a user is to log in with an email and password. If the user provides valid credentials, the server will either respond with a full user object including the token.
+     * The most common way to authenticate a user is to sign in with an email and password. If the user provides valid credentials, the server will either respond with a full user object including the token.
      *
-     * When the user's account is protected via MFA, the server will send a 6 digit code to the user via their default MFA provider. You should collect that code and resend the email, password and mfa_code together to get a successful authentication.
+     * When multi-factor authentication (MFA) protects the user's account, the server sends a six-digit code to the user through their default MFA provider. Collect that code and resend the `email`, `password`, and `mfa_code` together to get a successful authentication.
      *
      * The ideal flow for a login sequence is the following:
      *
-     * 1. Present an email address field only and allow the user to submit
-     * 2. Send `email` and `return_url` payload to this endpoint
-     * 3. Follow the flow based on the response `requires` field
+     * 1. Show an email address field only, and let the user submit it.
+     * 2. Send the `email` and `return_url` payload to this endpoint.
+     * 3. Follow the flow based on the response `requires` field.
      *
-     * Requires: `password`
+     * If `requires` is `password`:
      *
-     * 1. Show a password field for the user to fill out
-     * 2. Submit the `email` and `password` to this endpoint
-     * 3. If the response is `200`, the login is done. If the response is `201`, then check if `requires: mfa_code` is returned and show MFA flow
-     * 4. Submit `email`, `password`, `mfa_code` to this endpoint
+     * 1. To collect the password, show a password field for the user to fill out.
+     * 2. Submit the `email` and `password` to this endpoint.
+     * 3. If the response is `200`, the login is done. If the response is `201` and includes `requires: mfa_code`, show the MFA flow.
+     * 4. Submit `email`, `password`, and `mfa_code` to this endpoint.
      * 5. If the response is `200`, the login is done. Otherwise, show the appropriate error to the user and go back to step 1 or 3 depending on the error.
      *
-     * Requires: `saml_login`
+     * If `requires` is `saml_login`:
      *
-     * 1. [Open a browser](https://docs.expo.dev/versions/latest/sdk/webbrowser/#webbrowseropenauthsessionasyncurl-redirecturl-options) to the url returned in `sso_url`
-     * 2. User completes sign-in using their configured SAML IdP
-     * 3. Site redirects to your selected `return_url`
-     * 4. The `user_token` will be appended as a query string parameter to your `return_url` - you must parse this token and store it
-     * 5. Fetch the user object from `/users/me` using the token
+     * 1. [Open a browser](https://docs.expo.dev/versions/latest/sdk/webbrowser/#webbrowseropenauthsessionasyncurl-redirecturl-options) to the URL returned in `sso_url`.
+     * 2. Wait for the user to complete sign-in with their configured Security Assertion Markup Language (SAML) identity provider (IdP).
+     * 3. Expect a redirect to your selected `return_url`.
+     * 4. Parse the `user_token` query string parameter that the site appends to your `return_url`, and store it.
+     * 5. Fetch the user object from `/users/me` using the token.
      *
-     * ## Finishing a "Login with Green Security" flow
+     * ## Finish a "Login with Green Security" flow
      *
-     * Green Security is also a SAML2 **identity provider**. When a third-party service provider sends a user to
-     * `/saml/idp/sso` to sign in with their Green Security account, the user lands on a Green Security login screen
-     * carrying an `sso_state` query string parameter. That parameter is a signed, five-minute record of which service
+     * Green Security is also a SAML 2.0 **identity provider**. When a third-party service provider sends a user to
+     * `/saml/idp/sso` to sign in with Green Security, the user lands on a Green Security sign-in screen.
+     * That screen carries an `sso_state` query string parameter. That parameter is a signed, five-minute record of which service
      * provider is waiting, where its assertion consumer service lives, and what `RelayState` it sent.
      *
-     * Authentication itself is unchanged - the user may still need a password, an MFA code, a magic link or a round trip
+     * Authentication itself does not change. The user might still need a password, an MFA code, a magic link, or a round trip
      * to their own SAML IdP, and every `requires` value above applies as normal. The only difference is that you must
      * echo `sso_state` back on **every** call in the sequence, unchanged, including the follow-up that carries the
      * `mfa_code`.
      *
      * Each `202` response carries the verified blob back to you in its own top-level `sso_state` field. Send back the
-     * value from the response you just received rather than the one you started with. The two are normally the same
-     * string, but re-sending your original copy is how a blob the server has already rejected gets resent, and it forces
+     * value from the response you received not the one you started with. The two are normally the same
+     * string. Re-sending your original copy resends a blob the server has already rejected, and it forces
      * you to hold login state you would otherwise not need.
      *
-     * 1. Read `sso_state` from the query string of the login screen you were sent to
+     * 1. Read `sso_state` from the query string of the sign-in screen the service provider sent the user to.
      * 2. Run the login exactly as you would otherwise, adding `sso_state` to each request body and taking the value for
-     *    the next request from the previous `202` response
-     * 3. On the `200` response, read `sso.continue_url`
-     * 4. Navigate the browser to `sso.continue_url` - a full page navigation, not a background fetch. It answers with a
+     *    the next request from the previous `202` response.
+     * 3. On the `200` response, read `sso.continue_url`.
+     * 4. Navigate the browser to `sso.continue_url`: a full page navigation, not a background fetch. It answers with a
      *    self-submitting form that delivers the signed `SAMLResponse` and the original `RelayState` to the service
-     *    provider
-     * 5. The service provider validates the assertion and the user is signed in on their side
+     *    provider.
+     * 5. Expect the service provider to validate the assertion and sign the user in on their side.
      *
      * On the `password_reset` leg the blob is **also** appended to `redirect_url` as a query parameter, alongside
-     * `return_url`. The browser follows that redirect and leaves the JSON body behind, so anything the remaining legs of
+     * `return_url`. The browser follows that redirect and drops the JSON body, so anything the remaining legs of
      * the login still need has to ride the URL. Preserve the query string exactly as given.
      *
-     * An invalid `sso_state` never fails a login. A forged, edited or expired blob is silently dropped and the request is
-     * then treated as an ordinary login, so valid credentials still return `200` - just with no `sso` object. Check for
-     * `sso` explicitly rather than reading `200` as proof the hand-off survived. When it is absent, do not retry with the
+     * An invalid `sso_state` never fails a login. A forged, edited, or expired blob is silently dropped. The request is
+     * then treated as an ordinary login, so valid credentials still return `200`, with no `sso` object. Check for
+     * `sso` explicitly, and do not read `200` as proof the hand-off survived. When it is absent, do not retry with the
      * same blob; the user has to start again from the service provider. See the
      * [Login with Green Security](https://greensecurity.apidocumentation.com/guides/sso-login-with-green-security)
      * guide for the service provider half of this flow.
@@ -151,9 +151,9 @@ export declare class Users extends ClientSDK {
      * Rotate API key
      *
      * @remarks
-     * Allows an API user to rotate their own API key. Note, the key rotation happens immediately so the user should be prepared to update their API key in their application for all subsequent requests.
+     * Rotates the API key of the calling API user. The rotation takes effect immediately, so update the API key in your application for all subsequent requests.
      *
-     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission - the caller's role and their relationship to the record decide what is returned.
+     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission. The caller's role and their relationship to the record determine what the endpoint returns.
      */
     rotateApiKey(options?: RequestOptions): Promise<operations.RotateApiKeyRotateApiKeyOk>;
     /**
@@ -162,30 +162,30 @@ export declare class Users extends ClientSDK {
      * @remarks
      * Returns a list of users linked to the requested user.
      *
-     * Pass `user_id=me` to fetch the linked users of the authenticated user. This
+     * Pass `user_id=me` to fetch the linked users of the authenticated user. This option
      * is allowed for any authenticated user type.
      *
-     * API users may additionally pass a numeric `user_id` to fetch another user's
+     * API users can additionally pass a numeric `user_id` to fetch another user's
      * linked users, provided they have an active app activation for that user.
-     * Non-API users may only pass `me`.
+     * Non-API users can pass only `me`.
      *
-     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission - the caller's role and their relationship to the record decide what is returned.
+     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission. The caller's role and their relationship to the record determine what the endpoint returns.
      */
     getLinkedUsers(request: operations.GetLinkedUsersRequest, options?: RequestOptions): Promise<operations.GetLinkedUsersGetLinkedUsersOk>;
     /**
      * Switch to linked account
      *
      * @remarks
-     * If a user has two different types of accounts (i.e. Company Manager and Vendor) this endpoint allows the integration to swap the token from the existing user to the linked account user. For API integrations, the `source_user_id` field is required and must be the ID of the user whose session will be switched into the target user's token.
+     * Swaps the token from the existing user to the linked account user, for a user who has two different types of accounts (a Company Manager account and a Vendor account). For API integrations, the `source_user_id` field is required and must be the ID of the user whose session the server switches to the target user's token.
      *
-     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission - the caller's role and their relationship to the record decide what is returned.
+     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission. The caller's role and their relationship to the record decide what the response includes.
      */
     switchAccount(request: operations.SwitchAccountRequestBody, options?: RequestOptions): Promise<operations.SwitchAccountResponseBody>;
     /**
      * Magic link
      *
      * @remarks
-     * It sends an email with a magic link to allow the user to log in.
+     * Sends an email with a magic link that lets the user sign in.
      *
      * **Permissions.** No authentication required.
      */
@@ -194,7 +194,7 @@ export declare class Users extends ClientSDK {
      * Password reset request
      *
      * @remarks
-     * It sends an email with a link for resetting a user's password.
+     * Queues an email with a link for resetting a user's password. The server delivers the email asynchronously.
      *
      * **Permissions.** No authentication required.
      */
@@ -203,8 +203,8 @@ export declare class Users extends ClientSDK {
      * Password reset
      *
      * @remarks
-     * Resets the a user's password using a password_reset_id that was sent to them via email.
-     * See /users/passwordresetrequest to initiate a password reset flow.
+     * Resets a user's password using the password reset token that the server emailed to the user.
+     * See `/users/passwordresetrequest` to start a password reset flow.
      *
      * **Permissions.** No authentication required.
      */
@@ -213,18 +213,23 @@ export declare class Users extends ClientSDK {
      * Change password
      *
      * @remarks
-     * Change the user's password to the new passed as parameter
+     * Changes the user's password to the value of `new_password`
      *
-     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission - the caller's role and their relationship to the record decide what is returned.
+     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission: the caller's role and their relationship to the record determine what the response contains.
      */
     changePassword(request: operations.ChangePasswordRequest, options?: RequestOptions): Promise<operations.ChangePasswordChangePasswordOk>;
     /**
      * Register profile picture metadata for S3 direct upload
      *
      * @remarks
-     * 'Register profile picture metadata for a user and obtain a presigned S3 upload URL. The flow is two-step: (1) call this endpoint with the image''s file name, content type, and size; (2) PUT the file bytes to the returned upload_url with the matching Content-Type header. The file is stored at user_profile_image/{id}{ext} in the uploads bucket, where {ext} is derived from image_file_name and may be empty, and is processed asynchronously (resize to tiny/thumb/large variants). Use ''me'' as the id for the authenticated user. Requires authentication and either self-ownership or ''users:edit'' permission. API users must be authorized via MarketplaceAppActivation for the target user.'
+     * Registers profile picture metadata for a user and returns a presigned Amazon Simple Storage Service (S3) upload URL. The flow has two steps:
      *
-     * **Permissions.** For a regular user, requires self-ownership or the `users.edit` permission. For an API user, `users.edit` is not checked at all — authorization instead runs through the caller's update access scope on the target user, which a `MarketplaceAppActivation` grants at the user or site level.
+     * 1. Call this endpoint with the image's filename, content type, and size in bytes.
+     * 2. Send the file bytes to the returned `upload_url` in an HTTP `PUT` request with a `Content-Type` header that matches `image_content_type`.
+     *
+     * Use `me` as the ID for the authenticated user. The server processes the image asynchronously and resizes it to tiny, thumb, and large variants.
+     *
+     * **Permissions.** For a regular user, requires self-ownership or the `users.edit` permission. For an API user, the API does not check `users.edit`. Authorization instead runs through the caller's update access scope on the target user, which a `MarketplaceAppActivation` grants at the user or site level.
      */
     updateUserProfilePicture(request: operations.UpdateUserProfilePictureRequest, options?: RequestOptions): Promise<operations.UpdateUserProfilePictureUpdateUserProfilePictureOk>;
 }

package/dist/commonjs/sdk/users.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"users.d.ts","sourceRoot":"","sources":["../../../src/sdk/users.ts"],"names":[],"mappings":"AAgBA,OAAO,EAAE,SAAS,EAAE,cAAc,EAAE,MAAM,gBAAgB,CAAC;AAC3D,OAAO,KAAK,UAAU,MAAM,+BAA+B,CAAC;AAC5D,OAAO,KAAK,UAAU,MAAM,+BAA+B,CAAC;AAG5D,qBAAa,KAAM,SAAQ,SAAS;IAClC;;;;;;;;;;;;;;;;;;;OAmBG;IACG,cAAc,CAClB,OAAO,EAAE,UAAU,CAAC,qBAAqB,EACzC,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,IAAI,CAAC;IAQ3B;;;;;;;;;;;;;;;OAeG;IACG,WAAW,CACf,OAAO,EAAE,UAAU,CAAC,kBAAkB,EACtC,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,IAAI,CAAC;IAQ3B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA6BG;IACG,UAAU,CACd,OAAO,EAAE,UAAU,CAAC,iBAAiB,EACrC,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,sBAAsB,CAAC;IAQ7C;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA0EG;IACG,gBAAgB,CACpB,OAAO,EAAE,UAAU,CAAC,2BAA2B,EAC/C,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,wBAAwB,CAAC;IAQ/C;;;;;;;OAOG;IACG,YAAY,CAChB,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,0BAA0B,CAAC;IAOjD;;;;;;;;;;;;;;OAcG;IACG,cAAc,CAClB,OAAO,EAAE,UAAU,CAAC,qBAAqB,EACzC,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,8BAA8B,CAAC;IAQrD;;;;;;;OAOG;IACG,aAAa,CACjB,OAAO,EAAE,UAAU,CAAC,wBAAwB,EAC5C,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,yBAAyB,CAAC;IAQhD;;;;;;;OAOG;IACG,SAAS,CACb,OAAO,EAAE,UAAU,CAAC,oBAAoB,EACxC,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,oBAAoB,CAAC;IAQ3C;;;;;;;OAOG;IACG,oBAAoB,CACxB,OAAO,EAAE,UAAU,CAAC,+BAA+B,EACnD,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,0CAA0C,CAAC;IAQjE;;;;;;;;OAQG;IACG,QAAQ,CACZ,OAAO,EAAE,UAAU,CAAC,mBAAmB,EACvC,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,kBAAkB,CAAC;IAQzC;;;;;;;OAOG;IACG,cAAc,CAClB,OAAO,EAAE,UAAU,CAAC,qBAAqB,EACzC,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,8BAA8B,CAAC;IAQrD;;;;;;;OAOG;IACG,wBAAwB,CAC5B,OAAO,EAAE,UAAU,CAAC,+BAA+B,EACnD,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,kDAAkD,CAAC;CAO1E"}
+{"version":3,"file":"users.d.ts","sourceRoot":"","sources":["../../../src/sdk/users.ts"],"names":[],"mappings":"AAgBA,OAAO,EAAE,SAAS,EAAE,cAAc,EAAE,MAAM,gBAAgB,CAAC;AAC3D,OAAO,KAAK,UAAU,MAAM,+BAA+B,CAAC;AAC5D,OAAO,KAAK,UAAU,MAAM,+BAA+B,CAAC;AAG5D,qBAAa,KAAM,SAAQ,SAAS;IAClC;;;;;;;;;;;;;;;;;;;OAmBG;IACG,cAAc,CAClB,OAAO,EAAE,UAAU,CAAC,qBAAqB,EACzC,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,IAAI,CAAC;IAQ3B;;;;;;;;;;;;;;;OAeG;IACG,WAAW,CACf,OAAO,EAAE,UAAU,CAAC,kBAAkB,EACtC,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,IAAI,CAAC;IAQ3B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA6BG;IACG,UAAU,CACd,OAAO,EAAE,UAAU,CAAC,iBAAiB,EACrC,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,sBAAsB,CAAC;IAQ7C;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA0EG;IACG,gBAAgB,CACpB,OAAO,EAAE,UAAU,CAAC,2BAA2B,EAC/C,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,wBAAwB,CAAC;IAQ/C;;;;;;;OAOG;IACG,YAAY,CAChB,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,0BAA0B,CAAC;IAOjD;;;;;;;;;;;;;;OAcG;IACG,cAAc,CAClB,OAAO,EAAE,UAAU,CAAC,qBAAqB,EACzC,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,8BAA8B,CAAC;IAQrD;;;;;;;OAOG;IACG,aAAa,CACjB,OAAO,EAAE,UAAU,CAAC,wBAAwB,EAC5C,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,yBAAyB,CAAC;IAQhD;;;;;;;OAOG;IACG,SAAS,CACb,OAAO,EAAE,UAAU,CAAC,oBAAoB,EACxC,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,oBAAoB,CAAC;IAQ3C;;;;;;;OAOG;IACG,oBAAoB,CACxB,OAAO,EAAE,UAAU,CAAC,+BAA+B,EACnD,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,0CAA0C,CAAC;IAQjE;;;;;;;;OAQG;IACG,QAAQ,CACZ,OAAO,EAAE,UAAU,CAAC,mBAAmB,EACvC,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,kBAAkB,CAAC;IAQzC;;;;;;;OAOG;IACG,cAAc,CAClB,OAAO,EAAE,UAAU,CAAC,qBAAqB,EACzC,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,8BAA8B,CAAC;IAQrD;;;;;;;;;;;;OAYG;IACG,wBAAwB,CAC5B,OAAO,EAAE,UAAU,CAAC,+BAA+B,EACnD,OAAO,CAAC,EAAE,cAAc,GACvB,OAAO,CAAC,UAAU,CAAC,kDAAkD,CAAC;CAO1E"}

package/dist/commonjs/sdk/users.js

@@ -28,15 +28,15 @@ class Users extends sdks_js_1.ClientSDK {
      * By default the response returns a compact profile (id, name, email,
      * phone, timezone, user type, and a handful of confirmation flags).
      *
-     * **Permissions.** Requires a valid token only - a caller may always read their own record.
+     * **Permissions.** Requires a valid token only: a caller can always read their own record.
      *
      * Supported `expand` values:
-     * - `user` — return the full user record, including all profile fields stored against the user (sensitive columns such as passwords, MFA codes, and payment-provider IDs are always omitted)
-     * - `user.email_preferences` — include the user's `email_preferences` block (notification recipients, weekly email flags, and — for company managers — `receive_vendor_emails`)
-     * - `user.payment_profile` — include the user's `payment_profile` block (card type, last four digits, validity flags) when expanded; if no payment profile is associated with the user, the response returns `payment_profile: null`
-     * - `company.location`, `company.vendor_type_restrictions`, `company.vendor_fields` — only valid for Company Manager users; embed extra fields on the user's company
+     * - `user`: return the full user record, including all profile fields stored against the user (sensitive columns such as passwords, MFA codes, and payment-provider IDs are always omitted)
+     * - `user.email_preferences`: include the user's `email_preferences` block (notification recipients, weekly email flags, and, for company managers, `receive_vendor_emails`)
+     * - `user.payment_profile`: include the user's `payment_profile` block (card type, last four digits, validity flags) when expanded; if the user has no payment profile, the response returns `payment_profile: null`
+     * - `company.location`, `company.vendor_type_restrictions`, `company.vendor_fields`: only valid for Company Manager users; embed extra fields on the user's company
      *
-     * Multiple values can be combined with commas, e.g.
+     * Combine multiple values with commas, for example,
      * `?expand=user.email_preferences,company.location`.
      */
     async getCurrentUser(request, options) {
@@ -52,11 +52,11 @@ class Users extends sdks_js_1.ClientSDK {
      * By default the response returns a compact profile (id, name, email,
      * phone, timezone, user type, and a handful of confirmation flags).
      *
-     * **Permissions.** Requires any of `users.view`, `vendors.view`, `contacts.view`, `inventory_managers.view` or `company_managers.view`. Which one applies depends on the target user's type; callers may always read their own record.
+     * **Permissions.** Requires any of `users.view`, `vendors.view`, `contacts.view`, `inventory_managers.view` or `company_managers.view`. Which one applies depends on the target user's type; callers can always read their own record.
      *
      * Supported `expand` values:
-     * - `user` — return the full user record (sensitive columns such as passwords and payment-provider IDs are always omitted)
-     * - `user.email_preferences` — include the user's `email_preferences` block (notification recipients, weekly email flags, and — for company managers — `receive_vendor_emails`)
+     * - `user`: return the full user record (sensitive columns such as passwords and payment-provider IDs are always omitted)
+     * - `user.email_preferences`: include the user's `email_preferences` block (notification recipients, weekly email flags, and, for company managers, `receive_vendor_emails`)
      */
     async getUserById(request, options) {
         return (0, fp_js_1.unwrapAsync)((0, usersGetUserById_js_1.usersGetUserById)(this, request, options));
@@ -69,13 +69,13 @@ class Users extends sdks_js_1.ClientSDK {
      * preferences of a user. Pass `me` as `{id}` to update the authenticated
      * user's own profile, or a positive integer user ID otherwise.
      *
-     * Only submitted fields are applied — unrecognised fields are silently ignored.
+     * The API applies only submitted fields and silently ignores unrecognized fields.
      * Changing `email` automatically resets `bounced_email` to `false`.
      *
      * Submitting `zip`, `state`, or `country` cross-checks the postal code against the
-     * resulting state/country (using the existing value for any of the three left out
+     * resulting state or country (using the existing value for any of the three left out
      * of the request). A code that is not shaped like a real postal code, or that
-     * provably belongs to a different state, is rejected with `422` naming the correct
+     * provably belongs to a different state, gets a `422` response naming the correct
      * state.
      *
      * Each subkey of `email_preferences` is independently optional; sending
@@ -98,71 +98,71 @@ class Users extends sdks_js_1.ClientSDK {
      * Logs user into the system
      *
      * @remarks
-     * This endpoint allows a user to authenticate themselves and retrieve a permanent token for access.
+     * Authenticates a user and returns a permanent token for access.
      *
-     * Permanent tokens should only ever be stored in an encrypted storage because they represent a fully logged in user.
+     * Store permanent tokens only in encrypted storage because they represent a fully signed-in user.
      *
-     * Users may log in with `email/password`, `SAML`, `magic link` or `mfa`. The application should handle all of the above as equally valid login methods.
+     * Users can sign in with `email/password`, `SAML`, `magic link` or `mfa`. The application should handle all of these as equally valid sign-in methods.
      *
-     * The most common way to authenticate a user is to log in with an email and password. If the user provides valid credentials, the server will either respond with a full user object including the token.
+     * The most common way to authenticate a user is to sign in with an email and password. If the user provides valid credentials, the server will either respond with a full user object including the token.
      *
-     * When the user's account is protected via MFA, the server will send a 6 digit code to the user via their default MFA provider. You should collect that code and resend the email, password and mfa_code together to get a successful authentication.
+     * When multi-factor authentication (MFA) protects the user's account, the server sends a six-digit code to the user through their default MFA provider. Collect that code and resend the `email`, `password`, and `mfa_code` together to get a successful authentication.
      *
      * The ideal flow for a login sequence is the following:
      *
-     * 1. Present an email address field only and allow the user to submit
-     * 2. Send `email` and `return_url` payload to this endpoint
-     * 3. Follow the flow based on the response `requires` field
+     * 1. Show an email address field only, and let the user submit it.
+     * 2. Send the `email` and `return_url` payload to this endpoint.
+     * 3. Follow the flow based on the response `requires` field.
      *
-     * Requires: `password`
+     * If `requires` is `password`:
      *
-     * 1. Show a password field for the user to fill out
-     * 2. Submit the `email` and `password` to this endpoint
-     * 3. If the response is `200`, the login is done. If the response is `201`, then check if `requires: mfa_code` is returned and show MFA flow
-     * 4. Submit `email`, `password`, `mfa_code` to this endpoint
+     * 1. To collect the password, show a password field for the user to fill out.
+     * 2. Submit the `email` and `password` to this endpoint.
+     * 3. If the response is `200`, the login is done. If the response is `201` and includes `requires: mfa_code`, show the MFA flow.
+     * 4. Submit `email`, `password`, and `mfa_code` to this endpoint.
      * 5. If the response is `200`, the login is done. Otherwise, show the appropriate error to the user and go back to step 1 or 3 depending on the error.
      *
-     * Requires: `saml_login`
+     * If `requires` is `saml_login`:
      *
-     * 1. [Open a browser](https://docs.expo.dev/versions/latest/sdk/webbrowser/#webbrowseropenauthsessionasyncurl-redirecturl-options) to the url returned in `sso_url`
-     * 2. User completes sign-in using their configured SAML IdP
-     * 3. Site redirects to your selected `return_url`
-     * 4. The `user_token` will be appended as a query string parameter to your `return_url` - you must parse this token and store it
-     * 5. Fetch the user object from `/users/me` using the token
+     * 1. [Open a browser](https://docs.expo.dev/versions/latest/sdk/webbrowser/#webbrowseropenauthsessionasyncurl-redirecturl-options) to the URL returned in `sso_url`.
+     * 2. Wait for the user to complete sign-in with their configured Security Assertion Markup Language (SAML) identity provider (IdP).
+     * 3. Expect a redirect to your selected `return_url`.
+     * 4. Parse the `user_token` query string parameter that the site appends to your `return_url`, and store it.
+     * 5. Fetch the user object from `/users/me` using the token.
      *
-     * ## Finishing a "Login with Green Security" flow
+     * ## Finish a "Login with Green Security" flow
      *
-     * Green Security is also a SAML2 **identity provider**. When a third-party service provider sends a user to
-     * `/saml/idp/sso` to sign in with their Green Security account, the user lands on a Green Security login screen
-     * carrying an `sso_state` query string parameter. That parameter is a signed, five-minute record of which service
+     * Green Security is also a SAML 2.0 **identity provider**. When a third-party service provider sends a user to
+     * `/saml/idp/sso` to sign in with Green Security, the user lands on a Green Security sign-in screen.
+     * That screen carries an `sso_state` query string parameter. That parameter is a signed, five-minute record of which service
      * provider is waiting, where its assertion consumer service lives, and what `RelayState` it sent.
      *
-     * Authentication itself is unchanged - the user may still need a password, an MFA code, a magic link or a round trip
+     * Authentication itself does not change. The user might still need a password, an MFA code, a magic link, or a round trip
      * to their own SAML IdP, and every `requires` value above applies as normal. The only difference is that you must
      * echo `sso_state` back on **every** call in the sequence, unchanged, including the follow-up that carries the
      * `mfa_code`.
      *
      * Each `202` response carries the verified blob back to you in its own top-level `sso_state` field. Send back the
-     * value from the response you just received rather than the one you started with. The two are normally the same
-     * string, but re-sending your original copy is how a blob the server has already rejected gets resent, and it forces
+     * value from the response you received not the one you started with. The two are normally the same
+     * string. Re-sending your original copy resends a blob the server has already rejected, and it forces
      * you to hold login state you would otherwise not need.
      *
-     * 1. Read `sso_state` from the query string of the login screen you were sent to
+     * 1. Read `sso_state` from the query string of the sign-in screen the service provider sent the user to.
      * 2. Run the login exactly as you would otherwise, adding `sso_state` to each request body and taking the value for
-     *    the next request from the previous `202` response
-     * 3. On the `200` response, read `sso.continue_url`
-     * 4. Navigate the browser to `sso.continue_url` - a full page navigation, not a background fetch. It answers with a
+     *    the next request from the previous `202` response.
+     * 3. On the `200` response, read `sso.continue_url`.
+     * 4. Navigate the browser to `sso.continue_url`: a full page navigation, not a background fetch. It answers with a
      *    self-submitting form that delivers the signed `SAMLResponse` and the original `RelayState` to the service
-     *    provider
-     * 5. The service provider validates the assertion and the user is signed in on their side
+     *    provider.
+     * 5. Expect the service provider to validate the assertion and sign the user in on their side.
      *
      * On the `password_reset` leg the blob is **also** appended to `redirect_url` as a query parameter, alongside
-     * `return_url`. The browser follows that redirect and leaves the JSON body behind, so anything the remaining legs of
+     * `return_url`. The browser follows that redirect and drops the JSON body, so anything the remaining legs of
      * the login still need has to ride the URL. Preserve the query string exactly as given.
      *
-     * An invalid `sso_state` never fails a login. A forged, edited or expired blob is silently dropped and the request is
-     * then treated as an ordinary login, so valid credentials still return `200` - just with no `sso` object. Check for
-     * `sso` explicitly rather than reading `200` as proof the hand-off survived. When it is absent, do not retry with the
+     * An invalid `sso_state` never fails a login. A forged, edited, or expired blob is silently dropped. The request is
+     * then treated as an ordinary login, so valid credentials still return `200`, with no `sso` object. Check for
+     * `sso` explicitly, and do not read `200` as proof the hand-off survived. When it is absent, do not retry with the
      * same blob; the user has to start again from the service provider. See the
      * [Login with Green Security](https://greensecurity.apidocumentation.com/guides/sso-login-with-green-security)
      * guide for the service provider half of this flow.
@@ -176,9 +176,9 @@ class Users extends sdks_js_1.ClientSDK {
      * Rotate API key
      *
      * @remarks
-     * Allows an API user to rotate their own API key. Note, the key rotation happens immediately so the user should be prepared to update their API key in their application for all subsequent requests.
+     * Rotates the API key of the calling API user. The rotation takes effect immediately, so update the API key in your application for all subsequent requests.
      *
-     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission - the caller's role and their relationship to the record decide what is returned.
+     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission. The caller's role and their relationship to the record determine what the endpoint returns.
      */
     async rotateApiKey(options) {
         return (0, fp_js_1.unwrapAsync)((0, usersRotateApiKey_js_1.usersRotateApiKey)(this, options));
@@ -189,14 +189,14 @@ class Users extends sdks_js_1.ClientSDK {
      * @remarks
      * Returns a list of users linked to the requested user.
      *
-     * Pass `user_id=me` to fetch the linked users of the authenticated user. This
+     * Pass `user_id=me` to fetch the linked users of the authenticated user. This option
      * is allowed for any authenticated user type.
      *
-     * API users may additionally pass a numeric `user_id` to fetch another user's
+     * API users can additionally pass a numeric `user_id` to fetch another user's
      * linked users, provided they have an active app activation for that user.
-     * Non-API users may only pass `me`.
+     * Non-API users can pass only `me`.
      *
-     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission - the caller's role and their relationship to the record decide what is returned.
+     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission. The caller's role and their relationship to the record determine what the endpoint returns.
      */
     async getLinkedUsers(request, options) {
         return (0, fp_js_1.unwrapAsync)((0, usersGetLinkedUsers_js_1.usersGetLinkedUsers)(this, request, options));
@@ -205,9 +205,9 @@ class Users extends sdks_js_1.ClientSDK {
      * Switch to linked account
      *
      * @remarks
-     * If a user has two different types of accounts (i.e. Company Manager and Vendor) this endpoint allows the integration to swap the token from the existing user to the linked account user. For API integrations, the `source_user_id` field is required and must be the ID of the user whose session will be switched into the target user's token.
+     * Swaps the token from the existing user to the linked account user, for a user who has two different types of accounts (a Company Manager account and a Vendor account). For API integrations, the `source_user_id` field is required and must be the ID of the user whose session the server switches to the target user's token.
      *
-     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission - the caller's role and their relationship to the record decide what is returned.
+     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission. The caller's role and their relationship to the record decide what the response includes.
      */
     async switchAccount(request, options) {
         return (0, fp_js_1.unwrapAsync)((0, usersSwitchAccount_js_1.usersSwitchAccount)(this, request, options));
@@ -216,7 +216,7 @@ class Users extends sdks_js_1.ClientSDK {
      * Magic link
      *
      * @remarks
-     * It sends an email with a magic link to allow the user to log in.
+     * Sends an email with a magic link that lets the user sign in.
      *
      * **Permissions.** No authentication required.
      */
@@ -227,7 +227,7 @@ class Users extends sdks_js_1.ClientSDK {
      * Password reset request
      *
      * @remarks
-     * It sends an email with a link for resetting a user's password.
+     * Queues an email with a link for resetting a user's password. The server delivers the email asynchronously.
      *
      * **Permissions.** No authentication required.
      */
@@ -238,8 +238,8 @@ class Users extends sdks_js_1.ClientSDK {
      * Password reset
      *
      * @remarks
-     * Resets the a user's password using a password_reset_id that was sent to them via email.
-     * See /users/passwordresetrequest to initiate a password reset flow.
+     * Resets a user's password using the password reset token that the server emailed to the user.
+     * See `/users/passwordresetrequest` to start a password reset flow.
      *
      * **Permissions.** No authentication required.
      */
@@ -250,9 +250,9 @@ class Users extends sdks_js_1.ClientSDK {
      * Change password
      *
      * @remarks
-     * Change the user's password to the new passed as parameter
+     * Changes the user's password to the value of `new_password`
      *
-     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission - the caller's role and their relationship to the record decide what is returned.
+     * **Permissions.** Requires a valid token. This endpoint is not gated on a named permission: the caller's role and their relationship to the record determine what the response contains.
      */
     async changePassword(request, options) {
         return (0, fp_js_1.unwrapAsync)((0, usersChangePassword_js_1.usersChangePassword)(this, request, options));
@@ -261,9 +261,14 @@ class Users extends sdks_js_1.ClientSDK {
      * Register profile picture metadata for S3 direct upload
      *
      * @remarks
-     * 'Register profile picture metadata for a user and obtain a presigned S3 upload URL. The flow is two-step: (1) call this endpoint with the image''s file name, content type, and size; (2) PUT the file bytes to the returned upload_url with the matching Content-Type header. The file is stored at user_profile_image/{id}{ext} in the uploads bucket, where {ext} is derived from image_file_name and may be empty, and is processed asynchronously (resize to tiny/thumb/large variants). Use ''me'' as the id for the authenticated user. Requires authentication and either self-ownership or ''users:edit'' permission. API users must be authorized via MarketplaceAppActivation for the target user.'
+     * Registers profile picture metadata for a user and returns a presigned Amazon Simple Storage Service (S3) upload URL. The flow has two steps:
      *
-     * **Permissions.** For a regular user, requires self-ownership or the `users.edit` permission. For an API user, `users.edit` is not checked at all — authorization instead runs through the caller's update access scope on the target user, which a `MarketplaceAppActivation` grants at the user or site level.
+     * 1. Call this endpoint with the image's filename, content type, and size in bytes.
+     * 2. Send the file bytes to the returned `upload_url` in an HTTP `PUT` request with a `Content-Type` header that matches `image_content_type`.
+     *
+     * Use `me` as the ID for the authenticated user. The server processes the image asynchronously and resizes it to tiny, thumb, and large variants.
+     *
+     * **Permissions.** For a regular user, requires self-ownership or the `users.edit` permission. For an API user, the API does not check `users.edit`. Authorization instead runs through the caller's update access scope on the target user, which a `MarketplaceAppActivation` grants at the user or site level.
      */
     async updateUserProfilePicture(request, options) {
         return (0, fp_js_1.unwrapAsync)((0, usersUpdateUserProfilePicture_js_1.usersUpdateUserProfilePicture)(this, request, options));

package/dist/commonjs/sdk/users.js.map

@@ -1 +1 @@
-{"version":3,"file":"users.js","sourceRoot":"","sources":["../../../src/sdk/users.ts"],"names":[],"mappings":";AAAA;;GAEG;;;AAEH,4EAAsE;AACtE,4EAAsE;AACtE,4EAAsE;AACtE,sEAAgE;AAChE,kEAA4D;AAC5D,gEAA0D;AAC1D,wFAAkF;AAClF,gFAA0E;AAC1E,wEAAkE;AAClE,0EAAoE;AACpE,oEAA8D;AAC9D,gGAA0F;AAC1F,4CAA2D;AAG3D,0CAA6C;AAE7C,MAAa,KAAM,SAAQ,mBAAS;IAClC;;;;;;;;;;;;;;;;;;;OAmBG;IACH,KAAK,CAAC,cAAc,CAClB,OAAyC,EACzC,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,4CAAmB,EACpC,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;;;;;;OAeG;IACH,KAAK,CAAC,WAAW,CACf,OAAsC,EACtC,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,sCAAgB,EACjC,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA6BG;IACH,KAAK,CAAC,UAAU,CACd,OAAqC,EACrC,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,oCAAe,EAChC,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA0EG;IACH,KAAK,CAAC,gBAAgB,CACpB,OAA+C,EAC/C,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,gDAAqB,EACtC,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;OAOG;IACH,KAAK,CAAC,YAAY,CAChB,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,wCAAiB,EAClC,IAAI,EACJ,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;;;;;OAcG;IACH,KAAK,CAAC,cAAc,CAClB,OAAyC,EACzC,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,4CAAmB,EACpC,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;OAOG;IACH,KAAK,CAAC,aAAa,CACjB,OAA4C,EAC5C,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,0CAAkB,EACnC,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;OAOG;IACH,KAAK,CAAC,SAAS,CACb,OAAwC,EACxC,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,kCAAc,EAC/B,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;OAOG;IACH,KAAK,CAAC,oBAAoB,CACxB,OAAmD,EACnD,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,wDAAyB,EAC1C,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;OAQG;IACH,KAAK,CAAC,QAAQ,CACZ,OAAuC,EACvC,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,gCAAa,EAC9B,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;OAOG;IACH,KAAK,CAAC,cAAc,CAClB,OAAyC,EACzC,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,4CAAmB,EACpC,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;OAOG;IACH,KAAK,CAAC,wBAAwB,CAC5B,OAAmD,EACnD,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,gEAA6B,EAC9C,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;CACF;AAvVD,sBAuVC"}
+{"version":3,"file":"users.js","sourceRoot":"","sources":["../../../src/sdk/users.ts"],"names":[],"mappings":";AAAA;;GAEG;;;AAEH,4EAAsE;AACtE,4EAAsE;AACtE,4EAAsE;AACtE,sEAAgE;AAChE,kEAA4D;AAC5D,gEAA0D;AAC1D,wFAAkF;AAClF,gFAA0E;AAC1E,wEAAkE;AAClE,0EAAoE;AACpE,oEAA8D;AAC9D,gGAA0F;AAC1F,4CAA2D;AAG3D,0CAA6C;AAE7C,MAAa,KAAM,SAAQ,mBAAS;IAClC;;;;;;;;;;;;;;;;;;;OAmBG;IACH,KAAK,CAAC,cAAc,CAClB,OAAyC,EACzC,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,4CAAmB,EACpC,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;;;;;;OAeG;IACH,KAAK,CAAC,WAAW,CACf,OAAsC,EACtC,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,sCAAgB,EACjC,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA6BG;IACH,KAAK,CAAC,UAAU,CACd,OAAqC,EACrC,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,oCAAe,EAChC,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA0EG;IACH,KAAK,CAAC,gBAAgB,CACpB,OAA+C,EAC/C,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,gDAAqB,EACtC,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;OAOG;IACH,KAAK,CAAC,YAAY,CAChB,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,wCAAiB,EAClC,IAAI,EACJ,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;;;;;OAcG;IACH,KAAK,CAAC,cAAc,CAClB,OAAyC,EACzC,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,4CAAmB,EACpC,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;OAOG;IACH,KAAK,CAAC,aAAa,CACjB,OAA4C,EAC5C,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,0CAAkB,EACnC,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;OAOG;IACH,KAAK,CAAC,SAAS,CACb,OAAwC,EACxC,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,kCAAc,EAC/B,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;OAOG;IACH,KAAK,CAAC,oBAAoB,CACxB,OAAmD,EACnD,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,wDAAyB,EAC1C,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;OAQG;IACH,KAAK,CAAC,QAAQ,CACZ,OAAuC,EACvC,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,gCAAa,EAC9B,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;OAOG;IACH,KAAK,CAAC,cAAc,CAClB,OAAyC,EACzC,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,4CAAmB,EACpC,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;IAED;;;;;;;;;;;;OAYG;IACH,KAAK,CAAC,wBAAwB,CAC5B,OAAmD,EACnD,OAAwB;QAExB,OAAO,IAAA,mBAAW,EAAC,IAAA,gEAA6B,EAC9C,IAAI,EACJ,OAAO,EACP,OAAO,CACR,CAAC,CAAC;IACL,CAAC;CACF;AA5VD,sBA4VC"}