SDKs
ReadyTwo families. Eight backend SDKs — Go, Python, TypeScript, Java, .NET, Rust, Ruby, PHP — each an idiomatic native library over the relying-party IdentityService, held to mechanical parity so the same call behaves identically in every language. And two device SDKs — Swift and Kotlin — for embedding the authenticator into your own mobile app. All of it is Apache 2.0; the source and each library publish at general availability, the libraries to their language’s usual registry.
Who this is for: anyone choosing how to integrate. If you are wiring a backend to Ydentifi, you want a backend SDK (or raw gRPC). If you are putting the authenticator inside your own app, you want a device SDK — start at When to embed. If you just want the standalone app, you need no SDK at all.
Two families#
They sit on opposite sides of the ceremony, and you rarely need both.
An idiomatic library over the relying-party gRPC surface — create users, issue challenges, verify approvals, manage devices. This is what your application backend calls.
Go · Python · TypeScript · Java · .NET · Rust · Ruby · PHP. See the API reference for every method.
Embed enrollment, hardware-backed signing, and the approval UI directly in your own iOS or Android app, instead of sending users to the standalone Ydentifi app.
Only needed if you embed — the decision, and its trade-offs, are laid out in When to embed.
The backend SDKs#
Eight languages, each a real native library rather than a thin gRPC stub — idiomatic types, idiomatic errors (the typed error detail surfaces the same reason in each), mTLS wired for you. You install the one for your stack from its normal registry; there is nothing Ydentifi-specific about how you add it. The coordinates below are the published names — the registry artifacts and the source are published at general availability.
| Language | Install as | Public repo |
|---|---|---|
| Go | github.com/ydentifi/go | github.com/ydentifi/go |
| Python | ydentifi · PyPI | github.com/ydentifi/python |
| TypeScript | @ydentifi/client · npm | github.com/ydentifi/typescript |
| Java | com.ydentifi:client · Maven Central | github.com/ydentifi/java |
| .NET | Ydentifi.Client · NuGet | github.com/ydentifi/dotnet |
| Rust | ydentifi · crates.io | github.com/ydentifi/rust |
| Ruby | ydentifi · RubyGems | github.com/ydentifi/ruby |
| PHP | ydentifi/client · Packagist | github.com/ydentifi/php |
Every backend SDK wraps the same gRPC service, and that service is the real contract — you can generate a client from the published proto and call it directly. The SDKs exist because idiomatic beats generated, not because gRPC is off-limits. The API reference shows the raw-gRPC path alongside each language.
The same call, three ways
Idiomatic means idiomatic — the shape of a call belongs to its language, not to gRPC:
// create an opaque user
id, err := c.CreateUser(ctx,
ydentifi.User{})# create an opaque user
uid = client.create_user()// create an opaque user
const id =
await client.createUser();Every RPC, every language#
The promise is not “most of the API in most languages.” It is every RPC, as a method, on every SDK — and it is mechanically enforced, not maintained by hand.
Two guarantees hold the family together:
- Full coverage. A reflection test walks the service and fails the build if any RPC is missing a method in any SDK. The list of intentional exceptions is empty, and stays empty — there is no “that one is only in the Go client.”
- Identical behavior. One shared scenario suite runs against all eight SDKs; if any SDK returns a different verdict for the same scenario, the divergence blocks merge. A bug that made one language behave subtly differently would be caught before it shipped, because that is exactly the failure this is built to prevent.
So the language you pick is a matter of your stack, never of what you can do. The reference behavior is the API; the SDKs are eight faithful renderings of it.
The device SDKs#
Swift and Kotlin are a different job: they put the authenticator inside your app — the hardware-bound key in the Secure Enclave or Keystore, the enrollment handshake, the approval behind a biometric check — so your users never leave your product to approve. iOS-first, both Apache 2.0.
| Platform | Install via | Guide · reference |
|---|---|---|
| iOS — Swift | Swift Package Manager | Swift SDK · reference |
| Android — Kotlin | Maven Central | Kotlin SDK · reference |
Under the SDK is the device-facing gRPC surface — the same one the standalone app speaks. If you would rather drive it directly, it is documented at Device-facing gRPC.
Which one you want#
| You are… | Reach for |
|---|---|
| integrating a backend / relying party | a backend SDK in your language — or raw gRPC. Start at Quickstart. |
| building auth into your own mobile app | a device SDK (Swift / Kotlin). Start at When to embed. |
| happy to use the standalone app | no SDK — users install the Ydentifi authenticator and enroll against your deployment. |
Every SDK is Apache 2.0 and public, under github.com/ydentifi. The client code is meant to be read — there is no obligation to trust a black box you embed in your product. Registry artifacts publish at general availability; until then the sources are the reference.