In short
Two integration routes: an SDK that embeds recognition in your own application and process, and an HTTP API deployed inside your environment. This page explains which to choose, what an evaluation includes, and what is confirmed in writing before you commit engineering time.
Two routes
Where the recognition runs decides everything else
Latency, language flexibility and operational burden all follow from this one choice, so it is worth making deliberately rather than by default.
SDK
In your process
Detection, quality assessment, enrolment, 1:1, 1:N, tracking and liveness embedded directly in your application. No network hop, and the video never leaves.
Typical fit: a terminal, a gate, an edge device, one high-throughput application.
API
In your environment
An HTTP service deployed on your own infrastructure, callable from any language, with your own base URL, credentials and data residency.
Typical fit: several consuming applications, a mixed-language estate, a back office.
Recognition is available to customer applications through an SDK and an HTTP API
- Source type
- Ayonix first-party statement
- Verified
- 2026-09-11 · Jan Mocary, Chief Technology Officer
What this does not establish
Confirms that an SDK and an HTTP API exist. It does not establish any specific function name, endpoint path, language binding or operating-system build, none of which is published on this site.
Choosing
The trade, stated plainly
Neither route is better in general. These are the factors that actually decide it for a given application.
| SDK — in-process | API — service | |
|---|---|---|
| Where recognition runs | Inside your application process | In a service inside your environment |
| Latency | Supported: Lowest — no network hop | Partial: Adds a local round trip |
| Language flexibility | Partial: Bound to supported bindings | Supported: Any language that speaks HTTP |
| Serving several applications | Partial: Each embeds its own instance | Supported: One deployment, many callers |
| Upgrade burden | Version each embedding application | One service to upgrade |
| Template lifecycle | Your implementation to build and protect | Handled by the service you operate |
| Air-gapped deployment | Supported: Supported | Supported: Supported |
Many deployments use both. The SDK where a decision cannot wait for a network, the API for the applications that consume the result.
What you get
What an evaluation actually includes
Agreed in writing before it starts, so that neither side is working from a different idea of what the word means.
A build for your confirmed target
Operating system, architecture and calling language confirmed in writing first, so the first thing you receive actually runs on the thing you are building for.
The interface reference for that build
Versioned against what you received. This is why no reference is published on this site — one not tied to a specific build causes bugs rather than saving time.
Integration guidance
Threading and concurrency, resource lifetime, error handling and version upgrade behaviour. The things that determine whether the integration survives its first busy day.
An evaluation licence
With its terms stated up front: what it binds to, how long it lasts, and how it behaves with no network. Settled first for an air-gapped target.
An integration engineer
Someone who can discuss capture geometry, threshold selection and concurrency rather than only commercial terms.
A measurement method
How to establish a threshold on your own data, measuring both error types. Without this an evaluation produces an impression rather than a number.
Why these pages contain no example code with real function names
No verified public Ayonix interface reference was available when this site was built. Publishing plausible-looking function names or endpoint paths would cost whoever copied them a day of confusion, and cost this site its credibility permanently. The SDK page therefore carries a clearly labelled conceptual sequence, and the API page describes operations rather than paths. Both defer the real reference to the point where it can be released against a real build.
Frequently asked questions
Should I use the SDK or the API?
The SDK when recognition must run inside your own process: lowest latency, no network hop, and the video never leaves your application. The API when several applications need recognition, when your stack is in a language the SDK does not bind to, or when you would rather operate one service than embed a library in many. Many deployments use both — the SDK embedded at the gate where latency matters, the API for the applications behind it.
Why does this site not publish an API reference or SDK function names?
Because no verified public Ayonix interface contract was available when these pages were written, and inventing plausible identifiers would be actively harmful: developers copy code from vendor pages. What is published instead is the integration model, the operation set, the error taxonomy and the lifecycle — enough to design an integration. The reference, versioned against the build or deployment you receive, is released with an evaluation.
What does an evaluation include?
A build or deployment for your confirmed target, the interface reference for it, integration guidance covering threading, resource lifetime and error handling, an evaluation licence with stated terms, and access to an integration engineer. The scope and duration are agreed in writing before it starts, so neither side is guessing about what "evaluation" means.
Which platforms and languages are supported?
Confirmed in writing for your target before an evaluation begins, rather than published as a matrix. An untested compatibility matrix is exactly the kind of unsupported claim this site refuses to make elsewhere, and publishing one here would be inconsistent. State your operating system, architecture and calling language when requesting an evaluation.
Can I evaluate offline or in an air-gapped environment?
Yes — on-premise, edge and fully air-gapped deployment are supported. The detail that matters for an air-gapped evaluation is licence issuance and validation without a network, and it should be raised at the start because it constrains the rest of the design rather than being a configuration choice at the end.
Next step
Request an evaluation
Tell us the target platform, the calling language, the latency budget and the gallery size. What comes back is a supported-configuration confirmation and an evaluation scope agreed in writing — not a platform matrix nobody has tested.