Official Go SDK for Stream
Official Go API client for Stream Chat and Video, a service for building chat and video applications.
Explore the docs »
Report Bug
·
Request Feature
If you are currently using stream-chat-go, we have a detailed migration guide with side-by-side code examples for common Chat use cases. See the Migration Guide.
Stream allows developers to rapidly deploy scalable feeds, chat messaging and video with an industry leading 99.999% uptime SLA guarantee.
Stream provides UI components and state handling that make it easy to build video calling for your app. All calls run on Stream's network of edge servers around the world, ensuring optimal latency and reliability.
Stream is free for most side and hobby projects. To qualify, your project/company needs to have < 5 team members and < $10k in monthly revenue. Makers get $100 in monthly credit for video for free.
This repo contains the Golang server-side SDK developed by the team and Stream community. For a feature overview please visit our roadmap.
The client accepts a custom logger via WithLogger (any type implementing the Logger interface: Debug/Info/Warn/Error). Without one, it falls back to a stderr logger at INFO level, so per-request DEBUG events are silent by default; inject a logger with DEBUG enabled to see them.
Four structured events are emitted: client.initialized (INFO, once at construction, with SDK name/version and connection-pool settings), http.request.sent (DEBUG, before each request), http.response.received (DEBUG, after any response including 4xx/5xx, status codes are just data on this event), and http.request.failed (ERROR, transport-layer failures only, e.g. connection reset, timeout, DNS, TLS, when no HTTP response was received at all).
Security: these events never log HTTP headers (so Authorization is never written to logs), and known-secret values are always redacted regardless of logger: query parameters api_key, api_secret, and token become <redacted>, and top-level JSON body keys api_secret, token, and password become <redacted>. Request/response bodies are not logged by default. Opt in with WithLogBodies(true) if you need them for debugging, this logs a one-time WARN on construction because other sensitive data (message content, PII) may still appear in bodies even with the known-secret keys redacted.
Auto-retry is opt-in and off by default: the client performs exactly one attempt and surfaces errors unchanged unless you enable it with WithRetry:
client, err := stream.NewClient(apiKey, apiSecret,
stream.WithRetry(stream.RetryConfig{Enabled: true, MaxAttempts: 3, MaxBackoff: 30 * time.Second}),
)MaxAttempts (default 3) is the total attempt budget including the initial request; MaxBackoff (default 30s) caps every wait between attempts, including Retry-After hints from the server. Only GET/HEAD requests are retried, and only on HTTP 429 (rate limited) or a transport-layer failure (connection reset, timeout, DNS, TLS) — never on other 4xx/5xx responses, never on writes, and never when the backend marks the error unrecoverable. Waits use exponential backoff with full jitter (base 1s) unless the server sent a Retry-After header, which takes priority (clamped to MaxBackoff). A retried attempt logs http.request.failed at DEBUG with a retry.attempt field; a final (non-retried) transport failure still logs it at ERROR as before.
We welcome code changes that improve this library or fix a problem, please make sure to follow all best practices and add tests if applicable before submitting a Pull Request on Github. We are very happy to merge your code in the official repository. Make sure to sign our Contributor License Agreement (CLA) first. See our license file for more details.
Head over to CONTRIBUTING.md for some development tips.
To regenerate the Go source from OpenAPI, just run the ./generate.sh script from this repo.
Note Code generation currently relies on tooling that is not publicly available. Only Stream developers can regenerate SDK source code from the OpenAPI spec.
We've recently closed a $38 million Series B funding round and we keep actively growing. Our APIs are used by more than a billion end-users, and you'll have a chance to make a huge impact on the product within a team of the strongest engineers all over the world.
Check out our current openings and apply via Stream's website.