@stable_sea/sdk 0.2.11 → 0.2.13

package/README.md

@@ -53,6 +53,66 @@ keys and rotations reuse that data.
 WTGXX supports standard and instant settlement. FLTTX supports standard
 settlement; instant orders are refused in both production and sandbox.
 
+## Member administration and personal actions
+
+Use `createStableSeaSessionClient` for your profile and security, team and API-key
+administration, notifications, preferences and business support messages. It uses
+the native sign-in, MFA and business-selection flow,
+not a Live or Test API key. Use `https://api.stablesea.com`; the isolated
+Test-key Sandbox does not serve member sessions.
+
+```ts
+import { createStableSeaSessionClient } from "@stable_sea/sdk";
+
+// authenticatedFetch is your transport retaining the existing sign-in cookies.
+const member = createStableSeaSessionClient({
+  baseUrl: "https://api.stablesea.com",
+  fetch: authenticatedFetch,
+});
+const feed = await member.GET("/notifications/member_notifications");
+if (feed.error) throw new Error("Could not read notifications");
+console.log(feed.data.data);
+```
+
+Node.js fetch does not retain cookies automatically. Supply your authenticated
+transport. Call the typed sign-in and refresh operations explicitly; the client
+does not perform authentication, cookie storage or retries automatically.
+Existing login MFA, business membership, locks and permissions remain in force.
+Member requests do not use the dated financial API contract header.
+
+Member writes use `member.POST`, with each native operation's retry behavior.
+They have no financial `mutation()` helper. Key creation and rotation require
+an `Idempotency-Key`; other operations retain their documented native retry
+behavior. After an
+uncertain message send, match the returned `id` in the thread against the
+`message_id` you sent before resending;
+repeated sends can repeat notifications. Contact submissions must not retry
+automatically. See the [member guide](https://docs.stablesea.com/api/#member-sessions)
+for sign-in, session lifecycle and attachment retrieval, and the
+[member reference](https://docs.stablesea.com/api/member-reference/) for fields.
+
+List members at `GET /identity/members` and manage invitations at
+`/identity/members/invites`. Creation returns invitation details, never the
+redemption token delivered to the invitee. Invitation acceptance uses the
+invitee's email-link token; administrators cannot accept on their behalf.
+Member grants and activation use existing business permissions. Policy settings
+retain their separate launch gate.
+
+Manage Live and Test credentials at `/identity/api_keys`. Use an explicit scope
+list and a unique issuance idempotency key. Test lifecycle operations have no
+extra fresh two-factor prompt; Live operations retain their existing protection.
+Key management requires the same permission as Terminal and never broadens an
+existing credential's scopes implicitly.
+
+Native refresh and extension retain their existing `Success` and `Message`
+response keys. HTTP 200 with `Success: false` is a refusal. Sign-out returns an
+empty HTTP 200 after durable revocation and cookie clearing. Preserve the refresh
+cookie's `/platform_identity_api/auth/token` path; the session countdown is
+advisory, not proof of authentication.
+
+Generated types are exported as `SessionPaths`, `SessionOperations` and
+`SessionComponents`; internal operator and excluded product operations are omitted.
+
 ## Idempotent writes
 
 Create one mutation handle for one logical write. Its `POST` method always sends