Getting Started with the AIOZ Stream Go SDK Client

The Node.js SDK article already covered what creating and uploading a video actually involves conceptually. The Go client does the same job against the same API, and the differences that actually matter aren't syntax, they're real Go idioms: explicit error returns, a context parameter for cancellation, and a client that reads like it was generated from a spec rather than hand-written, because it was.

TL;DR:

• Install with go get github.com/AIOZNetwork/aioz-stream-go-client, then build a client with aiozstreamsdk.ClientBuilder(apiCreds).Build(), a builder pattern rather than the Node SDK's plain constructor.
• Every call returns an explicit error to check, and UploadVideo takes a context.Context as its first parameter, Go's standard mechanism for cancellation and timeouts, something the Node SDK's promise-based calls don't expose the same way.
• Request structs use pointer-typed optional fields with generated Get/GetOk/Set method pairs on every field, the unmistakable signature of a client generated from an OpenAPI spec rather than written by hand.
• The README states chunking, pagination, and token refresh are "handled for you," while the same README's own example still shows a manual part-upload path, meaning the convenience layer is there but isn't the only option.
• The playlist reorder request struct, MoveVideoInPlaylistRequest, uses the identical CurrentId/NextId/PreviousId fields covered in the Playlist API article, real confirmation the SDK and the raw API agree on how reordering actually works.

Install and initialize

go get github.com/AIOZNetwork/aioz-stream-go-client pulls the package. Client setup uses a builder rather than a constructor call: build an AuthCredentials struct with a public and secret key, then chain it through ClientBuilder(apiCreds).Build() to get a usable client. That's a real difference from the Node SDK's new StreamClient({ publicKey, secretKey }), not just a stylistic one, Go's builder pattern separates constructing a configuration from producing the final object, which matters more once a client needs optional configuration beyond just the two keys, retry settings or a custom HTTP client, for instance, without the constructor call growing an ever-longer parameter list.

Three Go idioms that actually change how you write this code

Every call in the Go client returns an explicit error value to check immediately, if err != nil, rather than a thrown exception a try/catch block catches somewhere up the stack, or a rejected promise a .catch() handles asynchronously the way the Node SDK works. That's not a minor stylistic choice, it means error handling in Go happens inline, at the exact call site, every time, rather than being something that can be deferred to a catch block further away. UploadVideo takes a context.Context as its first argument, Go's standard mechanism for propagating cancellation signals and deadlines through a call chain, so a caller can cancel an in-progress upload or set a timeout on it directly through the context rather than through a separate timeout parameter or an external abort mechanism. And request objects like CreateVideoRequest use pointer-typed fields for anything optional, paired with generated GetX(), GetXOk(), and SetX() methods for every single field, a pattern that only shows up when a client library is generated from a machine-readable API spec rather than written directly against the API by a person, the docs folder itself is organized as one file per request/response type rather than one guide per resource, another clear generated-client signature.

Creating and uploading a video

The documented flow mirrors the Node SDK's two-step shape, create the object, then upload the file, just written with Go's idioms in place: build a video creation payload, call client.Video.Create(videoData), pull the returned ID out of the response, then call client.UploadVideo(context.Background(), *videoId, fileName, videoFile, fileSize). context.Background() is the simplest possible context, no cancellation or deadline attached, a reasonable default for a script but worth swapping for a context with an actual timeout in a production service where an upload that hangs forever shouldn't be allowed to. Error handling follows the same explicit pattern throughout: check the error from Create before touching the returned ID, then check the error from UploadVideo separately, each step failing independently and explicitly rather than one exception potentially masking which step actually went wrong. The shape of that, reconstructed from the client's own documented example rather than a verbatim copy, since exact variable naming varies by use case, looks roughly like this:

videoResp, err := client.Video.Create(videoData)
if err != nil {
    fmt.Fprintf(os.Stderr, "Error creating video: %v\n", err)
    return
}
videoId := videoResp.Id // extract the ID from the create response

err = client.UploadVideo(context.Background(), *videoId, fileName, videoFile, fileSize)
if err != nil {
    fmt.Fprintf(os.Stderr, "Error uploading video: %v\n", err)
    return
}

Two separate, explicit checkpoints, not one wrapped in a single try block the way the equivalent JavaScript would likely be written. That's more lines of code for the same two-step operation, and it's also impossible to accidentally skip past a step's failure without noticing, since the next line simply can't run correctly with a nil or zero-value result sitting where a real one was expected.

The automation claims, checked

The client's own README states plainly that it "streamlines the coding process. Chunking files is handled for you, as is pagination and refreshing your tokens." That's a real convenience layer, not just marketing copy, matching what the raw chunked-upload mechanics require manually when working directly against the REST API. Worth noting honestly: the same documentation that makes that claim still shows a manual part-upload path as an available alternative, which means the automatic chunking is a convenience option layered on top of the raw mechanism, not the only way to move data through the client, useful to know if a specific integration needs more direct control over chunk boundaries or retry behavior than the automatic path exposes. The token-refresh half of that same claim matters for a different reason: a long-lived server process using this client doesn't need its own background job watching for credential expiry and re-authenticating, the kind of housekeeping code that's easy to skip early on and then only discover missing once a token actually expires in production. Whether "handled for you" means the client silently retries a failed call after refreshing, or simply exposes a refreshed token for the caller to use on the next request, isn't spelled out in what's publicly documented, worth confirming directly against actual expired-token behavior before assuming either implementation in a service that can't afford an unexpected authentication failure.

Same API, verified consistency

One concrete way to check whether an SDK actually reflects the underlying API accurately rather than drifting from it: compare a specific request shape across both. The Go client's playlist-reordering request, MoveVideoInPlaylistRequest, defines exactly three optional pointer fields, CurrentId, NextId, and PreviousId, the identical neighbor-reference design covered directly in the Playlist API article for the raw REST endpoint. That's a small thing to check, but it's real evidence the generated client and the documented API agree on how a specific, somewhat unusual design choice actually works, rather than the SDK papering over it with a simplified interface that hides the real mechanism. That consistency check is worth running on any generated client before trusting its documentation over the raw API's, spot-check one specific, non-obvious design decision, not just a simple field name, across both and see if they actually agree, rather than assuming a generated wrapper faithfully mirrors every real quirk of what it wraps.

Frequently Asked Questions

How do I install the AIOZ Stream Go client?
go get github.com/AIOZNetwork/aioz-stream-go-client, then build a client with aiozstreamsdk.ClientBuilder(apiCreds).Build() using your public and secret keys.

Does the Go client handle chunked uploads automatically?
Yes, per the client's own documentation, though a manual part-upload path is also still available for cases needing more direct control.

Why does UploadVideo take a context.Context parameter?
It's Go's standard mechanism for cancellation and timeouts, letting a caller cancel an in-progress upload or bound it with a deadline directly, rather than through a separate parameter or external mechanism.

Why do request structs use pointer fields with Get/GetOk/Set methods?
That pattern is generated automatically by OpenAPI-spec-based client generators, a signal this client is generated from a machine-readable spec rather than hand-written against the API.

Is playlist reordering the same in the Go client as the raw API?
Yes, verified directly, the Go client's MoveVideoInPlaylistRequest uses the identical CurrentId/NextId/PreviousId neighbor-reference fields documented for the raw REST endpoint.

Should I always use context.Background() like the basic example shows?
Not in production. context.Background() has no timeout or cancellation attached; a real service should generally pass a context with an actual deadline instead.

Related Reading

• Import Existing HLS Video Without Re-Encoding: a real gap between the two: the Go client doesn't wrap this feature's source_url parameter yet
• Building a Video Analytics Dashboard: pulling the same analytics data from a Go backend for a server-rendered dashboard
• Handling API Rate Limits in Production: handling a 429 in Go's explicit error-return style
• Getting Started with the AIOZ Stream Node.js SDK: the same create/upload flow in JavaScript, for comparison
• Chunked Video Upload Tutorial: 50-200MB Parts Explained: the raw mechanics this client's automatic chunking wraps
• Building Custom Playlist Ordering with the Playlist API: the reorder mechanism this client's request struct matches exactly
• AIOZ Stream API Keys: the credential scopes this client authenticates with
• AIOZ Stream Developer Guide: the full API and SDK surface this client is part of

References

• AIOZNetwork/aioz-stream-go-client on GitHub: the installation instructions, client initialization pattern, and automation claims quoted above
• MoveVideoInPlaylistRequest documentation: the CurrentId/NextId/PreviousId struct fields verified above