Go SDK demo guide

The Go SDK repository includes a single-binary demo, demo/. It needs no front-end build step: once started, your browser shows a complete working chat UI. Use it to try every client feature of the SDK before writing code, or as a reference for calling im.Client.

Requirements

• Go 1.26.5 or later (matching the SDK's go.mod; no third-party dependencies).
• A reachable IM server address.
• At least two user accounts in the app (the demo signs in with passwords, and you need two accounts to message each other). Create test accounts in the console, or from your server with the user management API.

This is the user sign-in demo for the client SDK; it needs no Client Secret or signed callbacks. For an example that uses app credentials and receives signed callbacks, see the Go server demo.

Download and start

Download the client SDK + demo ZIP · SHA256 checksums

Unzip it, go into deeprespond-im-go-sdk-1.0.2, and run:

go run ./demo --api http://127.0.0.1:18480 \
  --app-key '组织#应用' --addr 127.0.0.1:8090

The SDK and the web page are in the package; you only need Go and a reachable IM service. Run the command from the root of the download or of the standalone GitHub repository. Only when using the IM monorepo source do you need to go into sdk/go first. To add the SDK to your own project, see Quickstart.

You can also build a binary in the deeprespond-im-go-sdk-1.0.2 directory:

go build -o godemo ./demo
./godemo --api http://127.0.0.1:18480 --app-key '组织#应用' --addr 127.0.0.1:8090

On Windows, use go build -o godemo.exe ./demo and then run godemo.exe.

Flags

Flag	Environment variable	Default	Description
--api		http://127.0.0.1:18480	IM server REST address; the WS address is derived from it
--app-key	APP_KEY		App identifier (org#app); startup fails without it
--addr		:8090	The demo's HTTP listen address
--debug		Off	Print SDK debug logs (connection, reconnects, events)

The browser connects to the demo, and the Go back end makes the IM REST and WebSocket requests, so --api must be reachable from the machine running the demo. When IM uses https://, the SDK's connection uses wss://. If you put an HTTPS reverse proxy in front of the demo itself, it must also forward WebSocket upgrade requests.

Using it

1. Open http://127.0.0.1:8090 in the browser (the port comes from --addr).
2. Sign in with a username and password from the app.
3. Each browser session (cookie) is a separate IM sign-in. To chat between two accounts, use a normal window and a private window (tabs in the same browser share the sign-in).

Both Go demos use the demo_sid cookie, so use separate browser contexts when switching between the client and server demos on the same host.

What it covers

Password sign-in with error messages, finding users and friend requests, one-to-one and group messaging (text, images, quote replies), read receipts, typing indicators, reactions (👍/❤️), recall and delete, drafts, pinning and muting conversations, creating and managing groups, device management (revoking a session kicks it offline), editing the profile, and signing out. The page adapts to narrow screens, so you can also try it in a phone browser.

How the demo is built

The demo is the best example of how to use the Go SDK. In one process, each browser session holds its own im.Client. The page connects to the demo back end over WebSocket, wsbridge.go maps the page's protocol to SDK calls, and SDK events are pushed back to the page in real time (bootstrap, convs, msgs, typing, kicked and so on).

浏览器 ⇄ demo 后端（HTTP + WebSocket 桥）⇄ im.Client（Go SDK）⇄ IM 服务端

For a real bot or integration, drop the bridge and the page and call im.Client directly from your program; see Quickstart and Events, sync and Store.

Troubleshooting and limits

Symptom	Check
Module not found or wrong Go version	Start from deeprespond-im-go-sdk-1.0.2 in the unzipped directory, and check that Go is 1.26.5 or later
Startup says the AppKey is missing	Whether --app-key or APP_KEY is org#app
Sign-in fails	The IM address, which app the account belongs to, the password, and whether the app allows password sign-in
Both windows are always the same account	Use different browsers or a private context; tabs share cookies
No messages arrive after signing in	Whether both sides finished connecting, and whether the demo back end can reach the IM WebSocket endpoint
Port already in use	Change --addr and open the matching address in the browser

The demo's browser sessions and SDK cache are in memory, so you sign in again after a restart; signing out ends the real user session. It demonstrates client messaging only; it has no audio/video, chat rooms or server management callbacks. For the source layout and how to run the tests, see the demo README.