readme: remove official integration section (#407)

* readme: remove official integration section

Official integration is no longer offered. Replace with self-host
focused "Getting Started" section.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs, ct_dashboard: remove official integration references

Remove official integration mentions from docs_web and customer
dashboard sign-in form since the program is discontinued.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs: update docs for self-hosting-only model

- Remove all "official integration" and partnership references
- Replace Google-only auth mentions with all 6 supported providers
  (Google, email, GitHub, X, Discord, Telegram)
- Remove demo.oko.app hosted links, point to local demo_web
- Add sdk_endpoint self-hosting configuration to all SDK guides
- Remove API key setup section that assumed hosted dashboard
- Update API reference auth docs to be provider-agnostic
- Mark Telegram as supported (no longer "coming soon")

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* ct_dashboard: fix biome format error (trailing blank line)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: claraexmachina

README.md

@@ -25,18 +25,10 @@ Everything is fully open source and Apache-2.0 licensed:
 - Modular Architecture: Orchestrator, adaptors, MPC services, and signing logic
   are self-hostable and auditable.
 
-## Integration and Support
+## Getting Started
 
-- Official Integration: Access enterprise-grade key share infrastructure,
-  dedicated monitoring and operational support, and comprehensive Dapp Dashboard
-  and User Dashboard interfaces.
-
-- Self-Host (Open Source): Utilize the Apache 2.0 components for complete
-  architectural control and customization.
-
-To accelerate Official Integration, submit
-[the form](https://form.typeform.com/to/MxrBGq9b) and you’ll receive the next
-step by email.
+All components are Apache 2.0 licensed and designed to be self-hosted, giving
+you complete architectural control and customization.
 
 [Demo](https://demo.oko.app) | [Docs](https://docs.oko.app)
 

apps/customer_dashboard/src/components/sign_in_form/sign_in_form.module.scss

@@ -67,25 +67,6 @@
   }
 }
 
-.betaSection {
-  background: var(--bg-secondary);
-  border-radius: 16px;
-  padding: 16px;
-  margin-top: 20px;
-  text-align: center;
-}
-
-.betaText {
-  margin: 0 0 12px 0;
-}
-
-.earlyAccessLink {
-  text-decoration: underline;
-
-  &:hover {
-    text-decoration: none;
-  }
-}
 
 @media (max-width: 480px) {
   .topHeader {

apps/customer_dashboard/src/components/sign_in_form/sign_in_form.tsx

@@ -87,17 +87,6 @@ export const SignInForm: FC = () => {
           Forgot password?
         </Typography>
       </Link>
-
-      <div className={styles.betaSection}>
-        <Typography
-          size="sm"
-          weight="medium"
-          color="tertiary"
-          className={styles.betaText}
-        >
-          Start your official integration to unlock all dashboard features!
-        </Typography>
-      </div>
     </Card>
   );
 };

apps/docs_web/docs/v0/api-reference/api-overview.md

@@ -5,8 +5,7 @@ sidebar_position: 1
 
 # API Overview
 
-These APIs allow your dApp to check user existence and handle sign-in via Google
-with Oko.
+These APIs allow your dApp to check user existence and handle sign-in with Oko.
 
 ## Service Endpoints
 
@@ -20,15 +19,15 @@ and transaction signing:
 
 ### `POST /tss/v1/user/signin`
 
-Sign in a user via Google OAuth. This endpoint will return an authentication
+Sign in a user via a supported social login provider. This endpoint will return an authentication
 token and related metadata on success.
 
 #### Request
 
 - **Method**: `POST`
 - **Path**: `/tss/v1/user/signin`
-- **Headers**: `Authorization: Bearer <Google ID Token>` (The token should be
-  issued via Google Sign-In)
+- **Headers**: `Authorization: Bearer <ID Token>` (The token should be
+  issued by the chosen auth provider: Google, email, GitHub, X, Discord, or Telegram)
 
 #### Response
 
@@ -217,7 +216,7 @@ Update wallet key share nodes for resharing after unrecoverable data loss.
 
 - **Method**: `POST`
 - **Path**: `/tss/v1/user/reshare`
-- **Headers**: `Authorization: Bearer <Google ID Token>`
+- **Headers**: `Authorization: Bearer <ID Token>`
 - **Body**:
 
 ```json
@@ -280,17 +279,17 @@ Examples of signing transactions:
 
 ## Authentication
 
-### Google OAuth Flow
+### Social Login Flow
 
 From `backend/tss_api/src/routes/user.ts`:
 
 **Sign-in endpoint:**
 
 ```
 POST /tss/v1/user/signin
-- Initiates Google OAuth authentication
+- Initiates social login authentication
 - Returns JWT token and user information for subsequent API calls
-- Requires Google OAuth token in Authorization header
+- Requires ID token from the chosen auth provider in Authorization header
 ```
 
 **User verification:**
@@ -315,7 +314,7 @@ POST /tss/v1/user/signin_silently
 ```
 POST /tss/v1/user/reshare
 - Updates wallet key share nodes after unrecoverable data loss
-- Requires Google OAuth token and reshared key shares
+- Requires auth provider ID token and reshared key shares
 ```
 
 ### JWT Token Usage
@@ -342,7 +341,7 @@ From `backend/tss_api/src/routes/`:
 ```
 POST /tss/v1/keygen
 Content-Type: application/json
-Headers: Authorization: Bearer <Google ID Token>
+Headers: Authorization: Bearer <ID Token>
 
 Purpose: Create distributed key shares and wallet entities
 Implementation: Coordinates threshold key generation protocol
@@ -699,17 +698,17 @@ Example API testing commands:
 ```bash
 # Test TSS authentication
 curl -X POST http://localhost:4200/tss/v1/user/signin \
-  -H "Authorization: Bearer <google-oauth-token>"
+  -H "Authorization: Bearer <id-token>"
 
 # Test email check
 curl -X POST http://localhost:4200/tss/v1/user/check \
   -H "Content-Type: application/json" \
   -d '{"email": "user@example.com"}'
 
-# Test key generation (requires Google OAuth token)
+# Test key generation (requires ID token from auth provider)
 curl -X POST http://localhost:4200/tss/v1/keygen \
   -H "Content-Type: application/json" \
-  -H "Authorization: Bearer <google-oauth-token>" \
+  -H "Authorization: Bearer <id-token>" \
   -d '{...}'
 ```
 

apps/docs_web/docs/v0/architecture.md

@@ -76,7 +76,7 @@ security, while eliminating the need to manage complex private keys themselves.
 ### 🚀 Better User Experience
 
 - **No browser extensions** - embedded directly in your application
-- **Google OAuth login** - familiar authentication flow for mainstream users
+- **Social login (Google, email, GitHub, X, Discord, Telegram)** - familiar authentication flow for mainstream users
 - **Cross-device compatibility** - works on mobile, desktop, any browser
 - **Seamless onboarding** - users don't need to learn about seed phrases or
   hardware wallets
@@ -189,7 +189,7 @@ console.log("Connected:", okoSvm.publicKey?.toBase58());
 
 - Wallet UI runs in secure iframe context
 - Key shares stored in separate, encrypted databases
-- Authentication handled through Google OAuth
+- Authentication handled through social login providers (Google, email, GitHub, X, Discord, Telegram)
 
 **Data Protection:**
 

apps/docs_web/docs/v0/getting-started/integration-overview.md

@@ -9,54 +9,23 @@ Oko can be used alongside existing wallet connection methods, including the
 Keplr browser extension and mobile app.
 
 Integration is simple. Just add social login to your onboarding flow and you're
-ready to go. We support Google, email, GitHub, X, and Discord login. Telegram support is coming soon.
-We also plan to allow users to connect wallets they already have installed, such
-as Keplr and MetaMask.
+ready to go. We support Google, email, GitHub, X, Discord, and Telegram login.
+## Getting Started
 
-## Integration Options
+All Oko components are Apache 2.0 licensed and designed to be self-hosted,
+giving you complete architectural control and customization.
 
-Oko can be adopted in two ways. Both paths are fully supported depending on the
-needs of your application.
-
-### 1. Self Host (Open source)
-
-Use Oko’s Apache 2.0 licensed components to deploy and operate your own wallet
+Use Oko's open source components to deploy and operate your own wallet
 infrastructure. This path is ideal for teams that want:
 
 - Full architectural control
 - On-premise deployment
 - The ability to customize key management, signing, and login flows
 
-If you’re planning to run it yourself, check out our
+If you're planning to run it yourself, check out our
 [self hosting guide](../standalone/self-hosting-standalone.md) for a detailed
 walkthrough.
 
-### 2. Official Integration
-
-Teams seeking enterprise grade key share infrastructure and dedicated
-operational support can choose official integration. This option provides:
-
-- Enterprise grade key share infrastructure
-- Monitoring and operational support
-- Access to the Oko Dapp Dashboard and User Dashboard
-
-If you want to explore this option, submit
-[this form](https://form.typeform.com/to/MxrBGq9b). Next steps will be shared by
-email.
-
-## Get Started with Official Integration
-
-Once you submit [this form](https://form.typeform.com/to/MxrBGq9b), we will send
-you a temporary password via email to access
-the [Oko dApp Dashboard](https://dapp.oko.app). Use the email address you
-provided in the form as your login ID. When you sign in for the first time,
-you'll receive a verification code via email. Enter the code to proceed, and
-you'll be prompted to set a new password.
-
-At the time of login, you should be able to see the API key that has already
-been issued to you. Detailed setup instructions are covered in
-the [Quick Start Guide](./quick-start.md).
-
 ## Why Choose Oko?
 
 Most wallets rely on a **single private key** that can be stolen, lost, or
@@ -83,5 +52,4 @@ failure while providing a superior user experience.
 
 Want to see threshold signatures in action? Experience the difference firsthand:
 
-**[🚀 Try the Live Demo](https://demo.oko.app)** - Sign transactions without any
-wallet setup required
+**🚀 Try the Demo** - Run `demo_web` locally to sign transactions without any wallet setup

apps/docs_web/docs/v0/getting-started/quick-start.md

@@ -34,25 +34,6 @@ npm install @oko-wallet/oko-sdk-core
 npm install @oko-wallet/oko-sdk-core-react-native
 ```
 
-## API Key Setup
-
-Before using the SDK, you'll need your API key from the
-[Oko dApp Dashboard](https://dapp.oko.app):
-
-```typescript
-// Set your API key (from the dApp Dashboard)
-const OKO_API_KEY = "your-api-key-here";
-
-// Configure the SDK with your API key
-const config = {
-  api_key: OKO_API_KEY,
-  theme: "dark", // "light" | "dark" (optional)
-};
-```
-
-> **📋 Note:** Get your API key from the dApp Dashboard after completing the
-> partnership process described in the
-> [Integration Overview](./integration-overview.md).
 
 ## Cosmos Integration
 
@@ -168,7 +149,7 @@ const signature = await svmWallet.sendTransaction(transaction, connection);
 
 **The power of Oko:** Use familiar APIs for Ethereum, Cosmos, and SVM chains,
 while giving users **one account** that works across **all ecosystems**. Same
-Google login, consistent experience.
+login, consistent experience.
 
 ```typescript
 import { OkoCosmosWallet } from "@oko-wallet/oko-sdk-cosmos";
@@ -197,7 +178,7 @@ const ethWallet = ethInitRes.data;
 const svmWallet = svmInitRes.data;
 
 // Users can interact with all three ecosystems seamlessly
-// Same Google account, same user experience!
+// Same account, same user experience!
 ```
 
 ## React Native
@@ -244,7 +225,7 @@ Understanding how Oko works will help you integrate it effectively:
 **User Experience:**
 
 1. User clicks "Connect Wallet" in your dApp
-2. User signs in with Google (handled automatically by the SDK)
+2. User signs in with a supported method — Google, email, GitHub, X, Discord, or Telegram (handled automatically by the SDK)
 3. Cryptographic key shares are generated using threshold signatures
 4. User can now sign transactions - no browser extensions needed!
 

apps/docs_web/docs/v0/index.md

@@ -27,8 +27,7 @@ accessible by any single party.
 
 Experience Oko in action:
 
-- **[Demo Application](https://demo.oko.app)** - Explore the Oko experience in a
-  live demo
+- **Demo Application** - Run `demo_web` locally to explore the Oko experience
 
 ## Why Oko
 
@@ -54,9 +53,7 @@ model.
 **Oko** solves this by providing an embedded onboarding flow that still
 preserves the interoperability of a global wallet address. Developers keep full
 control of the integration because everything from client to server is open
-source under Apache 2.0. Teams can run Oko entirely on their own infrastructure
-or choose official integration to use enterprise grade key share nodes and
-dashboards.
+source under Apache 2.0. Teams can run Oko entirely on their own infrastructure.
 
 ### Key Advantages
 
@@ -72,7 +69,7 @@ dashboards.
 
 - **No browser extensions** - embedded directly in your application
 - **No recovery phrases** - users don't need to manage complex private keys
-- **Social login (e.g. Google OAuth)** - familiar authentication flow
+- **Social login** - Google, email, GitHub, X, Discord, and Telegram
 - **Cross-device compatibility** - works on mobile, desktop, any browser
 - **Cross-application interoperability** - same, global wallet address across
   multiple Web3 apps
@@ -120,7 +117,7 @@ dashboards.
 - GitHub
 - Discord
 - X (Twitter)
-- Telegram (coming soon)
+- Telegram
 
 **Oko SDK**
 
@@ -152,8 +149,7 @@ Ready to integrate Oko into your application?
 
 ### 📚 **API Reference**
 
-- **[Authentication](api-reference/api-overview.md#authentication)** - Google
-  OAuth and session management
+- **[Authentication](api-reference/api-overview.md#authentication)** - Social login and session management
 - **[Provider Methods](api-reference/api-overview.md)** - Complete API reference
 
 ---

apps/docs_web/docs/v0/lifecycle.md

@@ -36,17 +36,17 @@ if (!initRes.success) {
 const ethWallet = initRes.data;
 const provider = await ethWallet.getEthereumProvider();
 
-// This triggers Google OAuth authentication
-// User sees: "Sign in with Google" popup
-// User completes Google OAuth flow
+// This triggers social login authentication
+// User sees: login provider selection or sign-in popup
+// User completes the chosen provider's auth flow
 // Returns: JWT token for subsequent API calls
 ```
 
 **API Call Behind the Scenes:**
 
 ```
 POST /tss/v1/user/signin
-Headers: Authorization: Bearer <Google ID Token>
+Headers: Authorization: Bearer <ID Token>  (token issued by the chosen auth provider)
 Response: {
   "success": true,
   "data": {
@@ -544,7 +544,7 @@ if (ethWallet && ethWallet.okoWallet) {
 3. **Standard interface**: Uses familiar Web3 methods (`eth_sendTransaction`,
    etc.)
 4. **No private keys**: Users never see or manage cryptographic material
-5. **Google OAuth**: Familiar authentication flow
+5. **Social login**: Familiar authentication flow (Google, email, GitHub, X, Discord, Telegram)
 6. **Cross-application**: Same wallet works across different dApps
 
 **Performance Characteristics:**

apps/docs_web/docs/v0/sdk-usage/cosmos-integration.md

@@ -26,6 +26,7 @@ import { OkoCosmosWallet } from "@oko-wallet/oko-sdk-cosmos";
 const initRes = OkoCosmosWallet.init({
   api_key: "your-api-key",
   theme: "dark",
+  sdk_endpoint: "https://your-oko-attached.example.com", // your self-hosted oko_attached URL
 });
 
 if (!initRes.success) {