@sublay/js 7.8.0 → 7.9.1

package/dist/index.d.mts

@@ -190,7 +190,7 @@ declare function signIn(client: SublayHttpClient, data: SignInProps): Promise<Si
  * (server `src/constants/push/pushEvents.ts`); these are the only names a
  * `disabledTypes` set may contain.
  */
-declare const PUSH_EVENT_TYPES: readonly ["entity-comment", "comment-reply", "entity-mention", "comment-mention", "entity-reaction", "comment-reaction", "entity-reaction-milestone-specific", "entity-reaction-milestone-total", "comment-reaction-milestone-specific", "comment-reaction-milestone-total", "new-follow", "connection-request", "connection-accepted", "space-membership-approved", "event-invite", "event-updated", "event-cancelled", "message"];
+declare const PUSH_EVENT_TYPES: readonly ["entity-comment", "comment-reply", "entity-mention", "comment-mention", "entity-reaction", "comment-reaction", "entity-reaction-milestone-specific", "entity-reaction-milestone-total", "comment-reaction-milestone-specific", "comment-reaction-milestone-total", "new-follow", "connection-request", "connection-accepted", "space-membership-approved", "event-invite", "event-updated", "event-cancelled", "reputation-grant", "message"];
 type PushEventType = (typeof PUSH_EVENT_TYPES)[number];
 /**
  * The four conversation-mute duration choices. Send the CHOICE, never a raw
@@ -445,18 +445,35 @@ interface VerifyEmailProps {
 }
 declare function verifyEmail(client: SublayHttpClient, data: VerifyEmailProps): Promise<void>;
 
-interface SendVerificationEmailProps {
-    /** "code" emails a short token; "link" emails a verification URL. Defaults to "code". */
-    mode?: "code" | "link";
+interface SendCodeVerificationEmailHexProps {
+    mode: "code";
+    tokenFormat: "hex";
+    tokenLength?: never;
+}
+interface SendCodeVerificationEmailShortProps {
+    mode: "code";
+    tokenFormat: "numeric" | "alpha" | "alphanumeric";
+    tokenLength: number;
+}
+interface SendLinkVerificationEmailProps {
+    mode: "link";
     tokenFormat?: "hex" | "numeric" | "alpha" | "alphanumeric";
     tokenLength?: number;
-    /** For mode "link": where to send the user after the link is verified. */
+    /** Where to send the user after the link is verified. */
     redirectUrl?: string;
 }
+/**
+ * `mode` is required so every caller explicitly decides code vs link, and the
+ * `tokenFormat`/`tokenLength` pair for "code" is a discriminated union rather
+ * than two independent optionals — pairing `mode: "code"` with the default
+ * `tokenFormat: "hex"` used to compile fine and silently email a 64-character
+ * string no one could type.
+ */
+type SendVerificationEmailProps = SendCodeVerificationEmailHexProps | SendCodeVerificationEmailShortProps | SendLinkVerificationEmailProps;
 interface SendVerificationEmailResponse {
     success: boolean;
 }
-declare function sendVerificationEmail(client: SublayHttpClient, data?: SendVerificationEmailProps): Promise<SendVerificationEmailResponse>;
+declare function sendVerificationEmail(client: SublayHttpClient, data: SendVerificationEmailProps): Promise<SendVerificationEmailResponse>;
 
 interface RequestAccountDeletionResponse {
     success: boolean;
@@ -1021,6 +1038,91 @@ declare namespace Users {
   export { Users_checkUsernameAvailability as checkUsernameAvailability, Users_createBlock as createBlock, Users_createFollow as createFollow, Users_deleteBlock as deleteBlock, deleteFollow$1 as deleteFollow, Users_fetchBlockStatus as fetchBlockStatus, Users_fetchBlockedUsers as fetchBlockedUsers, Users_fetchConnectionStatus as fetchConnectionStatus, Users_fetchConnectionsByUserId as fetchConnectionsByUserId, Users_fetchConnectionsCountByUserId as fetchConnectionsCountByUserId, Users_fetchFollowStatus as fetchFollowStatus, Users_fetchFollowersByUserId as fetchFollowersByUserId, Users_fetchFollowersCountByUserId as fetchFollowersCountByUserId, Users_fetchFollowingByUserId as fetchFollowingByUserId, Users_fetchFollowingCountByUserId as fetchFollowingCountByUserId, Users_fetchUserByForeignId as fetchUserByForeignId, Users_fetchUserById as fetchUserById, Users_fetchUserByUsername as fetchUserByUsername, Users_fetchUserSuggestions as fetchUserSuggestions, Users_removeConnectionByUserId as removeConnectionByUserId, Users_requestConnection as requestConnection, Users_updateUser as updateUser };
 }
 
+/** The three grantable target kinds. Polymorphic — `targetId` carries no FK. */
+type ReputationGrantTargetType = "entity" | "comment" | "chat-message";
+/**
+ * Who created the grant. `"user"` is a debited transfer (reputation moved out
+ * of `senderId`'s bucket); `"app"` is a mint issued by the project itself with
+ * a null `senderId`. Persisted rather than inferred from `senderId`, which is
+ * also null for a transfer whose sender was later deleted.
+ */
+type ReputationGrantSourceType = "user" | "app";
+/**
+ * The "which item was rewarded" pair, as a both-or-neither union.
+ *
+ * Modelled as a two-branch union rather than two independent optional fields so
+ * a half-filled target — `{ targetType }` with no `targetId`, or the reverse —
+ * does not compile. The server answers that shape with
+ * `400 reputation-grant/invalid-body` on the write (a shared
+ * `bothOrNeitherTarget` refinement) and
+ * `400 reputation-grant/invalid-filter` on the list, so the union turns a
+ * guaranteed round trip into a red squiggle.
+ *
+ * The empty branch is `?: undefined`, NOT `?: null` — deliberately, and for the
+ * same reason `metadata` is not nullable: `grantBodyFields.targetType` is
+ * `.optional()` with no `.nullable()`, so an explicit `targetType: null` is
+ * rejected. Omit both keys to mean "no target".
+ *
+ * Building the pair conditionally needs one accommodation: an inline
+ * conditional spread of just these two keys widens both to `T | undefined` and
+ * then matches neither branch. Either branch the whole argument, or name this
+ * type on a helper and spread that:
+ *
+ * ```ts
+ * const target: ReputationGrantTargetFilter = item
+ *   ? { targetType: "entity", targetId: item.id }
+ *   : {};
+ * await listGrants(client, { ...base, ...target });
+ * ```
+ */
+type ReputationGrantTargetFilter = {
+    /** The kind of item rewarded. Requires `targetId` alongside it. */
+    targetType: ReputationGrantTargetType;
+    /** The rewarded item's id. Requires `targetType` alongside it. */
+    targetId: string;
+} | {
+    targetType?: undefined;
+    targetId?: undefined;
+};
+/**
+ * Per-item reputation-grant summary. Covers positive grants only — negative
+ * grants (app deductions) are invisible on every public read surface.
+ */
+interface GrantSummary {
+    /** Sum of positive grant amounts on the item. */
+    total: number;
+    /** Number of positive grants on the item. */
+    count: number;
+    /** The calling user's own summed positive grants on the item. */
+    viewerTotal: number;
+}
+/**
+ * A single reputation movement. Rows are append-only — nothing updates or
+ * soft-deletes them — so the table is the audit log behind every balance.
+ */
+interface ReputationGrant {
+    id: string;
+    sourceType: ReputationGrantSourceType;
+    /** Null for an app mint, and for a transfer whose sender was deleted. */
+    senderId: string | null;
+    /** Populated when the list is called with `include: "user"`. */
+    sender?: User | null;
+    recipientId: string;
+    /** Populated when the list is called with `include: "user"`. */
+    recipient?: User | null;
+    /** Non-zero. Negative only when `sourceType` is `"app"`. */
+    amount: number;
+    /** The bucket both legs moved in; null = the project-general bucket. */
+    spaceId: string | null;
+    /** Both null or both non-null. */
+    targetType: ReputationGrantTargetType | null;
+    targetId: string | null;
+    note: string | null;
+    metadata: Record<string, any> | null;
+    createdAt: string;
+    updatedAt: string;
+}
+
 type Mention = UserMention | SpaceMention;
 interface UserMention {
     type: "user";
@@ -1226,6 +1328,13 @@ interface Entity {
     nsfwEffective: boolean;
     topComment: TopComment | null;
     isSaved?: boolean;
+    /**
+     * Reputation-grant summary. Opt-in — present exactly when the read requested
+     * `include=grants`. Once requested the server always returns the object,
+     * zero-filled rather than omitted, on projects with no grants and on projects
+     * without the reputation bundle alike.
+     */
+    grants?: GrantSummary;
     isDraft: boolean | null;
     moderationStatus: "approved" | "removed" | null;
     moderatedAt: string | null;
@@ -1757,6 +1866,13 @@ interface Comment {
     reactionCounts: ReactionCounts;
     userReaction?: ReactionType | null;
     repliesCount: number;
+    /**
+     * Reputation-grant summary. Opt-in — present exactly when the read requested
+     * `include=grants`. Once requested the server always returns the object,
+     * zero-filled rather than omitted, on projects with no grants and on projects
+     * without the reputation bundle alike.
+     */
+    grants?: GrantSummary;
     metadata: Record<string, any>;
     createdAt: string;
     updatedAt: string;
@@ -2241,6 +2357,13 @@ interface ChatMessage {
     threadReplyCount: number;
     reactionCounts: Record<string, number>;
     userReactions: string[];
+    /**
+     * Reputation-grant summary. Opt-in — present exactly when the read requested
+     * `include=grants`. Once requested the server always returns the object,
+     * zero-filled rather than omitted, on projects with no grants and on projects
+     * without the reputation bundle alike.
+     */
+    grants?: GrantSummary;
     editedAt: string | null;
     userDeletedAt: string | null;
     moderationStatus: "approved" | "removed" | null;
@@ -2871,6 +2994,96 @@ declare namespace Reports {
   export { Reports_createReport as createReport, Reports_fetchModeratedReports as fetchModeratedReports };
 }
 
+interface CreateGrantBaseProps {
+    /** The user receiving the reputation. Cannot be the logged-in user. */
+    recipientId: string;
+    /**
+     * Positive integer. A user transfer can never mint (negatives) nor be a
+     * no-op (zero) — minting is service-key-only and lives in `@sublay/node`.
+     */
+    amount: number;
+    /** The bucket both legs move in. Omitted/null = the project-general bucket. */
+    spaceId?: string | null;
+    /**
+     * Free-text reason. Trimmed and capped at 2000 characters server-side.
+     * Genuinely nullable — an explicit `null` is accepted and means "no note".
+     */
+    note?: string | null;
+    /**
+     * Arbitrary JSON, capped at 1 MB server-side.
+     *
+     * NOT nullable — deliberately asymmetric with `note` directly above, not a
+     * typo. The server's shared `metadataSchema` is `z.record(...).optional()`
+     * with no `.nullable()`, so an explicit `metadata: null` is rejected with
+     * `400 reputation-grant/invalid-body`. Omit the key to mean "no metadata".
+     */
+    metadata?: Record<string, any>;
+}
+/**
+ * `targetType` and `targetId` are supplied together or not at all — the
+ * both-or-neither pair is carried by {@link ReputationGrantTargetFilter}, which
+ * makes the half-filled shape a compile error instead of a
+ * `400 reputation-grant/invalid-body`.
+ */
+type CreateGrantProps = CreateGrantBaseProps & ReputationGrantTargetFilter;
+/**
+ * Transfers reputation from the logged-in user to another user — a **debited
+ * transfer**: the amount leaves the sender's bucket and lands in the
+ * recipient's bucket in the same space. Nothing is created.
+ *
+ * There is no actor field: the sender is always the user the token belongs to.
+ * Naming somebody else as the sender requires a service key, which this SDK
+ * never holds.
+ */
+declare function createGrant(client: SublayHttpClient, data: CreateGrantProps): Promise<ReputationGrant>;
+
+interface ListGrantsBaseProps extends SpaceReputationContextParams {
+    page?: number;
+    limit?: number;
+    /** What this user received. */
+    recipientId?: string;
+    /** What this user sent. */
+    senderId?: string;
+    /** Associations to expand. Only `"user"` is supported (hydrates both parties). */
+    include?: string;
+}
+/**
+ * The third filter shape — "who rewarded this item" — is the
+ * {@link ReputationGrantTargetFilter} pair, so a half-filled target is a
+ * compile error rather than a `400 reputation-grant/invalid-filter`.
+ *
+ * Mutual exclusivity between the three shapes is NOT expressed in the type: a
+ * three-way exclusive union would multiply out across every pagination and
+ * space-reputation field and make the props unreadable, for a rule the server
+ * reports clearly. Only the both-or-neither pairing is typed.
+ */
+type ListGrantsProps = ListGrantsBaseProps & ReputationGrantTargetFilter;
+/**
+ * The `summary` block rides alongside the page envelope, and only on the
+ * target filter shape.
+ */
+interface ListGrantsResponse extends PaginatedResponse<ReputationGrant> {
+    summary?: GrantSummary;
+}
+/**
+ * Lists reputation grants.
+ *
+ * Exactly one filter shape per request — `recipientId`, `senderId`, or
+ * `targetType` + `targetId`. Supplying none or combining two is a `400`; the
+ * shapes are not AND-ed, which is what keeps the `summary` block reconcilable
+ * with the rows beneath it.
+ *
+ * Only positive grants are ever returned. Negative grants are app moderation
+ * deductions and are unreadable from every public surface.
+ */
+declare function listGrants(client: SublayHttpClient, data: ListGrantsProps): Promise<ListGrantsResponse>;
+
+declare const Reputation_createGrant: typeof createGrant;
+declare const Reputation_listGrants: typeof listGrants;
+declare namespace Reputation {
+  export { Reputation_createGrant as createGrant, Reputation_listGrants as listGrants };
+}
+
 interface SearchContentProps extends SpaceReputationContextParams {
     query: string;
     sourceTypes?: ("entity" | "comment" | "message")[];
@@ -3323,7 +3536,11 @@ interface ListMessagesProps extends SpaceReputationContextParams {
     /** Page size (default 50, max 100). */
     limit?: number;
     sort?: "asc" | "desc";
-    /** Comma-separated associations to populate, e.g. "files". */
+    /**
+     * Comma-separated associations to populate: `"files"` (message
+     * attachments) and `"grants"` (the reputation-grant summary). Combine
+     * them as `"files,grants"` — the server splits and trims this itself.
+     */
     include?: string;
     /** Optional filters, e.g. `{ hasReplies: true }`. */
     filters?: MessageFilters;
@@ -3363,6 +3580,11 @@ declare function sendMessage(client: SublayHttpClient, data: SendMessageProps):
 interface GetMessageProps extends SpaceReputationContextParams {
     conversationId: string;
     messageId: string;
+    /**
+     * Comma-separated associations to populate. Only `"grants"` is supported
+     * here — it attaches the message's reputation-grant summary.
+     */
+    include?: string;
 }
 declare function getMessage(client: SublayHttpClient, data: GetMessageProps): Promise<ChatMessage>;
 
@@ -3569,9 +3791,46 @@ interface WorkspaceInvitation {
     createdAt: string;
     updatedAt: string;
 }
+interface WorkspaceInvitationInviter {
+    id: string;
+    name: string | null;
+    username: string | null;
+    avatar: string | null;
+    reputation: number;
+}
+interface MyWorkspaceInvitation extends Omit<WorkspaceInvitation, "invitedBy"> {
+    workspace: {
+        id: string;
+        name: string;
+    };
+    invitedBy: WorkspaceInvitationInviter;
+}
 interface WorkspaceRosterReason {
     type: "owner" | "member" | "ancestor-owner" | "reach-holder" | "descendant-member";
     rank?: number;
+    /**
+     * The SAME ladder position, expressed as an offset from the CALLER: `1` = one
+     * rung below you, `0` = your peer, `-3` = three rungs above you. The caller's
+     * own anchor is their member row on this workspace if they hold one, and apex
+     * (one step above rank 0) if they do not — so a rank-0 member reads back as
+     * `relativeRank: 1` for an owner.
+     *
+     * Authority-bearing and fenced WITH `rank`, never beside it: it is `rank`
+     * minus a number the caller already knows, so leaking it leaks `rank` exactly.
+     *
+     * Present on same-node `member` reasons only. `descendant-member` entries
+     * carry `rank` but NEVER `relativeRank` — rank is per-workspace, so an offset
+     * measured against your standing on THIS node would be arithmetic across two
+     * different ladders. Use their absolute `rank` there.
+     *
+     * Note the deliberate asymmetry with the fence described above: the FENCE is
+     * per node (a descendant row may or may not carry `rank` depending on your
+     * standing there), but PRESENCE of `relativeRank` is not — it is absent on
+     * every `descendant-member` row, unconditionally, however much authority you
+     * hold. A field that appears and disappears by who is asking is worse to
+     * consume than one that is uniformly absent.
+     */
+    relativeRank?: number;
     capabilities?: WorkspaceCapability[];
     permissions?: string[];
     title?: string | null;
@@ -3611,6 +3870,13 @@ interface WorkspaceMemberStanding {
     capabilities?: WorkspaceCapability[];
     permissions?: string[];
     rank?: number | null;
+    /**
+     * `rank` expressed as an offset from the CALLER (negative = senior to you).
+     * `null` exactly when `rank` is `null` — a target with no direct member row
+     * here sits outside the ladder and has no position to measure. Fenced with
+     * `rank`: absent (not null) for a caller who may not see it.
+     */
+    relativeRank?: number | null;
     title: string | null;
     metadata: Record<string, any>;
 }
@@ -3683,7 +3949,11 @@ interface FetchManyWorkspacesProps {
 }
 /**
  * List the bearer-token user's direct-membership + owned workspaces. The actor
- * is derived from the token — no `userId` is sent.
+ * is derived from the token — no actor field is sent.
+ *
+ * ⚠️ Only the fields declared above are accepted. The workspaces endpoints
+ * refuse any undeclared top-level field with a 400 rather than ignoring it, so
+ * do not spread an unrelated object into `data`.
  */
 declare function fetchManyWorkspaces(client: SublayHttpClient, data?: FetchManyWorkspacesProps): Promise<PaginatedResponse<Workspace>>;
 
@@ -3694,7 +3964,7 @@ interface UpdateWorkspaceProps {
 }
 /**
  * Edit a workspace's name / metadata. Requires the `edit-workspace` capability
- * (or ownership). The actor is the bearer-token user — no `userId` is sent.
+ * (or ownership). The actor is the bearer-token user — no actor field is sent.
  */
 declare function updateWorkspace(client: SublayHttpClient, data: UpdateWorkspaceProps): Promise<Workspace>;
 
@@ -3706,7 +3976,7 @@ interface UpdateWorkspaceInheritFlagProps {
  * Flip whether capabilities held on an ancestor "reach" into this workspace.
  * Owner-only in both directions (own owner or an ancestor owner), and blocked
  * (403 `workspace/inherit-enforced`) when the project enforces its default.
- * The actor is the bearer-token user — no `userId` is sent.
+ * The actor is the bearer-token user — no actor field is sent.
  */
 declare function updateWorkspaceInheritFlag(client: SublayHttpClient, data: UpdateWorkspaceInheritFlagProps): Promise<Workspace>;
 
@@ -3718,8 +3988,8 @@ interface DeleteWorkspaceResponse {
 }
 /**
  * Owner-only delete (own owner or an ancestor owner). Cascades the whole
- * subtree transactionally. The actor is the bearer-token user — no `userId`
- * body is sent.
+ * subtree transactionally. The actor is the bearer-token user — no actor
+ * field is sent.
  */
 declare function deleteWorkspace(client: SublayHttpClient, data: DeleteWorkspaceProps): Promise<DeleteWorkspaceResponse>;
 
@@ -3732,7 +4002,7 @@ interface TransferWorkspaceOwnershipProps {
 }
 /**
  * Hand the workspace to a new owner. Owner-only (own owner or an ancestor
- * owner). The actor is the bearer-token user — no `userId` is sent;
+ * owner). The actor is the bearer-token user — no actor field is sent;
  * `newOwnerId` addresses the TARGET, not the actor.
  */
 declare function transferWorkspaceOwnership(client: SublayHttpClient, data: TransferWorkspaceOwnershipProps): Promise<Workspace>;
@@ -3746,6 +4016,11 @@ interface FetchWorkspaceMembersProps {
  * Unified roster read — one entry per distinct user, each with a `reasons`
  * array. Always returned in full (never paginated). With `countOnly=true` the
  * shape is `WorkspaceRosterCountsResponse` instead. Actor from the token.
+ *
+ * Same-node `member` reasons carry both rank coordinates: absolute `rank` and
+ * `relativeRank`, the offset from you (`1` = one rung below you, `-3` = three
+ * above). Both are fenced together and both are absent for a caller who does
+ * not operate people here. `descendant-member` reasons carry `rank` only.
  */
 declare function fetchWorkspaceMembers(client: SublayHttpClient, data: FetchWorkspaceMembersProps): Promise<WorkspaceRosterResponse | WorkspaceRosterCountsResponse>;
 
@@ -3755,7 +4030,11 @@ interface FetchWorkspaceMemberStandingProps {
 }
 /**
  * Read one user's resolved standing on a workspace (`reasons`, `capabilities`,
- * `permissions`, `rank`, `title`, `metadata`).
+ * `permissions`, `rank`, `relativeRank`, `title`, `metadata`).
+ *
+ * `relativeRank` is the target's `rank` as an offset from YOU (negative =
+ * senior to you), and is fenced with `rank`: both are absent, not null, for a
+ * caller who may not see the target's authority.
  */
 declare function fetchWorkspaceMemberStanding(client: SublayHttpClient, data: FetchWorkspaceMemberStandingProps): Promise<WorkspaceMemberStanding>;
 
@@ -3765,13 +4044,31 @@ interface UpdateWorkspaceMemberProps {
     capabilities?: WorkspaceCapability[];
     permissions?: string[];
     rank?: number;
+    /**
+     * `rank`'s relative twin: an offset from the ACTOR (`1` = one rung below me),
+     * resolved to an absolute rank at write time and stored absolute. Must be
+     * `>= 1`; mutually exclusive with `rank` (sending both is a 400). Both rank fields are also capped at `2147483647` (int4), and the RESOLVED sum is bounded too — an in-range anchor plus an in-range offset can still overflow, which is a 400 rather than a 500.
+     *
+     * The anchor is the actor's own rank if they hold a member row on this
+     * workspace, apex otherwise. A SNAPSHOT — frozen at write time, it does not
+     * follow the actor's own rank afterwards.
+     *
+     * Unlike invite, edit has NO default: omitting BOTH still means "rank
+     * unchanged", so editing someone's capabilities never moves them on the
+     * ladder.
+     */
+    relativeRank?: number;
     title?: string | null;
     metadata?: Record<string, any>;
 }
 /**
  * Edit a member's grant / profile. Powerful fields need `edit-member-access`
  * plus rank + no-escalation rules; cosmetic fields need only
- * `edit-member-profile`. No `userId` is sent — the actor comes from the token.
+ * `edit-member-profile`. No actor field is sent — the actor comes from the token.
+ *
+ * Rank moves in either coordinate — `rank` (absolute) or `relativeRank` (an
+ * offset from the actor) — never both. Omitting both leaves rank UNCHANGED;
+ * unlike invite, edit has no value default.
  */
 declare function updateWorkspaceMember(client: SublayHttpClient, data: UpdateWorkspaceMemberProps): Promise<WorkspaceMember>;
 
@@ -3782,7 +4079,7 @@ interface RemoveWorkspaceMemberProps {
 /**
  * Remove a member from this workspace. Requires the `remove-member` capability
  * and is rank-bounded. The workspace owner cannot be removed (409
- * `workspace/sole-owner`) — transfer ownership first. No `userId` body is sent;
+ * `workspace/sole-owner`) — transfer ownership first. No actor field is sent;
  * the actor comes from the token.
  */
 declare function removeWorkspaceMember(client: SublayHttpClient, data: RemoveWorkspaceMemberProps): Promise<void>;
@@ -3793,8 +4090,9 @@ interface LeaveWorkspaceProps {
 /**
  * The bearer-token user leaves this workspace — removes THEIR OWN direct
  * membership on THIS node only (owning a child is unaffected). An owner cannot
- * leave (409 `workspace/sole-owner`); transfer or delete first. No `userId` is
- * sent — the server derives the leaver from the token.
+ * leave (409 `workspace/sole-owner`) — transfer ownership or remove the
+ * workspace first. No actor field is sent; the server derives the leaver from
+ * the token.
  */
 declare function leaveWorkspace(client: SublayHttpClient, data: LeaveWorkspaceProps): Promise<void>;
 
@@ -3820,12 +4118,61 @@ interface CreateWorkspaceInviteProps {
     username?: string;
     capabilities?: WorkspaceCapability[];
     permissions?: string[];
-    rank: number;
+    /**
+     * The invited rank, ABSOLUTE — a position on this workspace's ladder (smaller
+     * = more senior). The escape hatch, and what tier-constant apps want, since
+     * they compute the number anyway.
+     *
+     * Optional, and mutually exclusive with `relativeRank` — sending both is a
+     * 400. Sending NEITHER defaults to `relativeRank: 1`, one rung below the
+     * inviter, which is well defined for every actor and can never fail the rank
+     * floor.
+     *
+     * ⚠️ That default is for a NEW invitation. Re-inviting a target who already
+     * has a live pending invite updates it in place, and there omitting both rank
+     * fields PRESERVES the stored rank instead of re-defaulting it. See the
+     * function doc below.
+     */
+    rank?: number;
+    /**
+     * The invited rank, RELATIVE to the inviter: `1` = one rung below me, `2` =
+     * two rungs below, and so on. The documented happy path — every governance
+     * rule about rank is relative, so this is what callers usually mean.
+     *
+     * Must be `>= 1` on a write. `0` would mean "a peer", which the assign rule
+     * forbids (you cannot clone your own authority), and a negative offset would
+     * mint someone senior to you; both are a 400. Both rank fields are also capped at `2147483647` (int4), and the RESOLVED sum is bounded too — an in-range anchor plus an in-range offset can still overflow, which is a 400 rather than a 500.
+     *
+     * The anchor is the inviter's OWN rank if they hold a member row on this
+     * workspace, and apex (one step above rank 0) if they do not — so an owner's
+     * `relativeRank: 1` lands on rank 0, while a rank-3 member's lands on rank 4.
+     *
+     * ⚠️ A SNAPSHOT, not a live link: the offset is resolved to an absolute rank
+     * once, at invite time, and frozen. It does not track the inviter's later
+     * promotions or demotions.
+     */
+    relativeRank?: number;
     title?: string | null;
 }
 /**
  * Create an invitation (requires the `invite` capability on the workspace). The
  * inviter is the bearer-token user.
+ *
+ * The invited rank comes in either coordinate — `rank` (absolute) or
+ * `relativeRank` (an offset from the inviter) — never both. Omitting both
+ * defaults to `relativeRank: 1`, one rung below the inviter, which is the
+ * documented happy path and can never fail the rank floor.
+ *
+ * ⚠️ This route doubles as an UPSERT, and the default above applies only to a
+ * NEW invitation. Re-inviting a target who already holds a live pending invite
+ * refreshes THAT invitation in place — same id, expiry reset — and on that
+ * branch an omitted grant field is PRESERVED, not re-defaulted or blanked:
+ * `rank`, `capabilities`, `permissions` and `title` all keep their stored
+ * values. A "Resend invitation" button that posts only the address therefore
+ * cannot silently re-rank the invitee to one below whoever clicked it. An
+ * explicit value still overwrites, and an explicit `relativeRank` re-resolves
+ * against the CURRENT caller. Full semantics:
+ * https://docs.sublay.io/api-reference/workspaces/invitations/create-invite
  */
 declare function createWorkspaceInvite(client: SublayHttpClient, data: CreateWorkspaceInviteProps): Promise<WorkspaceInvitation>;
 
@@ -3897,7 +4244,7 @@ interface DeclineWorkspaceInviteResponse {
 declare function declineWorkspaceInvite(client: SublayHttpClient, data: DeclineWorkspaceInviteProps): Promise<DeclineWorkspaceInviteResponse>;
 
 interface FetchMyWorkspaceInvitesResponse {
-    data: WorkspaceInvitation[];
+    data: MyWorkspaceInvitation[];
 }
 /**
  * The bearer-token user's LIVE pending invites (`status='pending' AND expiresAt
@@ -3917,6 +4264,11 @@ interface FetchWorkspaceAuthorityProps {
  * Authority-as-a-service read — the bearer-token user's resolved standing
  * (`{ reasons, capabilities, permissions, rank }`) on the workspace. A
  * permission check is a one-line `.includes()` on the result.
+ *
+ * ⚠️ No `relativeRank` on this read. It is an offset from the caller, and here
+ * the caller IS the subject — so it could only ever be `0`. `rank` is the only
+ * rank coordinate this endpoint exposes. `relativeRank` is meaningful on the
+ * roster and member-standing reads, where the subject is somebody else.
  */
 declare function fetchWorkspaceAuthority(client: SublayHttpClient, data: FetchWorkspaceAuthorityProps): Promise<WorkspaceAuthority>;
 
@@ -4022,6 +4374,7 @@ declare class SublayClient {
     connections: BoundModule<typeof Connections>;
     appNotifications: BoundModule<typeof AppNotifications>;
     reports: BoundModule<typeof Reports>;
+    reputation: BoundModule<typeof Reputation>;
     search: BoundModule<typeof Search>;
     storage: BoundModule<typeof Storage>;
     oauth: BoundModule<typeof OAuth>;
@@ -4042,4 +4395,4 @@ declare class SublayClient {
     clearTokens(): void;
 }
 
-export { type AuthTokens, type BulkDeleteProps, type BulkDeleteResult, type ClientConfig, type DbFilter, type DbFilterOperator, type DeleteResult, MUTE_DURATIONS, type MuteConversationProps, type MuteConversationResponse, type MuteDuration, type NotificationPreferences, PUSH_EVENT_TYPES, type PaginatedResponse, type PaginationMetadata, type PushDeviceIdentifier, type PushEventType, type PushUnbindSkipReason, type RemoveWorkspaceMemberFromSubtreeResponse, type SignOutResult, type SkippedWorkspace, type SpaceReputationContextParams, type SpaceReputationUserParams, SublayClient, type TableAccessor, type TableQuery, type TableRow, type UpdateNotificationPreferencesProps, type UserSearchParams, type WebPushSubscription, type Workspace, type WorkspaceAuthority, type WorkspaceAuthorityReason, type WorkspaceAuthorityReasonDetail, type WorkspaceCapability, type WorkspaceInvitation, type WorkspaceInvitationStatus, type WorkspaceMember, type WorkspaceMemberStanding, type WorkspaceRosterCountsResponse, type WorkspaceRosterEntry, type WorkspaceRosterReason, type WorkspaceRosterResponse, type WorkspaceStandingUser };
+export { type AuthTokens, type BulkDeleteProps, type BulkDeleteResult, type ClientConfig, type CreateGrantProps, type DbFilter, type DbFilterOperator, type DeleteResult, type GrantSummary, type ListGrantsProps, type ListGrantsResponse, MUTE_DURATIONS, type MuteConversationProps, type MuteConversationResponse, type MuteDuration, type MyWorkspaceInvitation, type NotificationPreferences, PUSH_EVENT_TYPES, type PaginatedResponse, type PaginationMetadata, type PushDeviceIdentifier, type PushEventType, type PushUnbindSkipReason, type RemoveWorkspaceMemberFromSubtreeResponse, type ReputationGrant, type ReputationGrantSourceType, type ReputationGrantTargetFilter, type ReputationGrantTargetType, type SignOutResult, type SkippedWorkspace, type SpaceReputationContextParams, type SpaceReputationUserParams, SublayClient, type TableAccessor, type TableQuery, type TableRow, type UpdateNotificationPreferencesProps, type UserSearchParams, type WebPushSubscription, type Workspace, type WorkspaceAuthority, type WorkspaceAuthorityReason, type WorkspaceAuthorityReasonDetail, type WorkspaceCapability, type WorkspaceInvitation, type WorkspaceInvitationInviter, type WorkspaceInvitationStatus, type WorkspaceMember, type WorkspaceMemberStanding, type WorkspaceRosterCountsResponse, type WorkspaceRosterEntry, type WorkspaceRosterReason, type WorkspaceRosterResponse, type WorkspaceStandingUser };