The snapWONDERS API has been open for a while — forensic analysis, format conversion, and snapWONDERS Vaultify’s steganography, all reachable over HTTPS and described by a published OpenAPI 3.x specification. Several developers reached out about integrating it, and the same nuance kept coming up in those conversations: the capabilities were exactly right, but getting past the file upload step took more work than it should.
That’s worth fixing properly, not just noting down.
Where the friction was
More than one of those conversations landed on the same step: the file upload. It isn’t a simple POST. Uploads to snapWONDERS go over TUS, the resumable upload protocol I’ve written about before — chunked, resumable, survives a dropped connection. That’s the right choice for a platform where people upload media over patchy connections, including Tor and I2P. It is also, if you’re implementing a client from scratch, genuinely fiddly: create the upload, encode the metadata header correctly, PATCH the chunks in order, handle a resume if a chunk fails. Roughly eighty lines of code that has to be exactly right before you ever see a result.
Nobody integrating a client should have to hand-write that eighty lines. So I built that part for them.
One call instead of eighty lines
The SDKs wrap the whole choreography — create a session, upload each file, start the job, poll until it finishes, download the results — behind one call:
from snapwonders import Client
client = Client(api_key="sw_your_key")
job = client.stego.hide(files=["secret.pdf", "cover.jpg"], password="Str0ng!Pass")
for result in job.results():
result.download(f"out/{result.name}")
There’s no business logic in the client. Every decision still happens on the server — the SDK’s entire job is making the correct-but-tedious part invisible.

Four languages, written the honest way
About ten percent of an API client can’t be generated from an OpenAPI spec — the TUS upload logic and the session-to-job choreography are exactly that ten percent, and exactly the part developers were flagging. So Python came first, hand-written, as the reference implementation. JavaScript/TypeScript followed the same way, ported by hand rather than generated, because getting the resumable-upload logic right the second time is still worth doing properly rather than mechanically. PHP and Go came after, generated from the live OpenAPI spec with the TUS helper ported across — the pattern was proven twice by then, so the long tail is genuinely cheap.
All four are open source and MIT-licensed:
Language
Package
Install
Source
Python (3.10+)
snapwonderspip install snapwondersGitHub
JavaScript / TypeScript (Node 18+)
@snapwonders/sdknpm install @snapwonders/sdkGitHub
PHP (8.2+)
snapwonders/sdkcomposer require snapwonders/sdkGitHub
Go (1.21+)
—
go get github.com/snapWONDERS/snapWONDERS-SDK-GoGitHub
Full quickstarts, side-by-side examples for every language, and the interactive API reference live on the developers hub.
The rest of the OpenAPI-generatable languages — Ruby, Java, C#, Rust, and so on — are a short step away: point openapi-generator at the published spec and you have a typed client in minutes, with only the TUS choreography left to hand-port. Want one added to the official set, hit an integration snag, or just have a question? Get in touch — that’s also where to report a bug in any of the four.
What I found testing it against the real API
Writing the client against documentation is one thing; running it against production is what actually finds the bugs. It found three. A failed job’s real reason lived in a field the SDK wasn’t reading. A directory download wrote a file literally named out instead of writing into the out/ directory, because a trailing slash on a path that doesn’t exist yet is easy to mishandle. And a maintenance window returned a response shape the SDK’s error handling didn’t recognise, so it retried into a five-minute outage instead of backing off. All three are the same lesson: build against the interface you assume exists, then go and check it against the one that actually responds.
Why this matters more than it looks like it should
The easier an API is to call, the more of it developers actually use. The forensic analysis, the conversion pipeline, the steganography — none of it is more useful to a developer than the least convenient step required to reach it. Fixing the upload wall doesn’t change what the platform does. It changes how much of it developers can put to work without fighting the plumbing first.
Kenneth Springer is the founder of snapWONDERS, a digital forensic analysis platform for images and video. This SDK work grew out of building snapWONDERS’ own developer API, which now ships official Python, JavaScript, PHP and Go clients so other developers can call the same forensic analysis, steganography and conversion tools programmatically. snapWONDERS forensic analysis — no account required.

