@stable_sea/sdk 0.2.12 → 0.2.13

package/README.md

@@ -53,10 +53,11 @@ 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 notifications and support
+## Member administration and personal actions
 
-Use `createStableSeaSessionClient` for personal notifications, preferences and
-business support messages. It uses an existing signed-in business session,
+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.
 
@@ -74,18 +75,41 @@ console.log(feed.data.data);
 ```
 
 Node.js fetch does not retain cookies automatically. Supply your authenticated
-transport; the client does not implement login, refresh or automatic retries.
+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 or idempotency-key replay. After an
+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.