Why it matters How it works Quickstart Privacy Try on RapidAPI →
idemapi logo
Fuzzy extractor logic for embeddings.

From similarity to certainty.

Stable, deterministic IDs from noisy embeddings. Think fuzzy extractors, but for complex, non-binary embeddings.

Face login Voice auth Document provenance Fraud and risk Device trust Any embedding model
Get API Access on RapidAPI → See how it works
Stable IDs for noisy embeddings - From similarity to certainty | Product Hunt
How it works

The product flow is simple.

Four steps. Two API calls. One equality check in your application.

Ready to test the flow yourself? Grab your key on RapidAPI and make your first Bind call in minutes.

Start Using idemapi →
01
IN

You send an embedding

Keep your current model. IdemAPI starts where your encoder output begins.

→
02
BN

We return anchor + ID

POST /v1/bind gives you stable material for future use. Nothing is stored server-side.

→
03
DB

You store them

Save the anchor and id in your own database, object store or keychain.

→
04
ID

You derive the ID later

POST /v1/derive with a fresh embedding plus the anchor. The server returns a derived ID. Your app compares it to the stored one.

Examples

The applications are broad. These are only a few concrete ones.

Once you can turn noisy embeddings into stable IDs, the pattern applies far beyond one product category. Here are three examples, shown end to end.

Real example

Face verification, shown as API calls and stored JSON.

This is only an example. The same bind-then-derive flow applies to any embedding generated by any model.

1
First face sample

User signs in for the first time

Your face model outputs an embedding. You send it to /v1/bind.

Request
POST /v1/bind
{
  "embedding": [0.14, -0.82, 0.33, 0.91, -0.27, 0.45, ...],
  "strictness": 0.55
}
Response
{
  "anchor": "0006a3f9...",
  "id": "f29c6ab1...",
  "dim": 512,
  "strictness": 0.55
}
2
Your storage

You persist only what you need

You store the returned material next to the user record. No raw embedding needs to live in your backend.

Your database row
{
  "user_id": "user_42",
  "anchor": "0006a3f9...",
  "id": "f29c6ab1..."
}
3
Later login attempt

You derive from a fresh observation

The user comes back, your model emits a new embedding, and you call /v1/derive with that embedding plus the stored anchor.

Request
POST /v1/derive
{
  "embedding": [0.11, -0.80, 0.31, 0.89, -0.24, 0.48, ...],
  "anchor": "0006a3f9..."
}
Response
{
  "id": "f29c6ab1..."
}
4
Your application logic

You do one exact comparison

Your backend compares the returned ID with the stored ID. Equal means same source. Different means reject.

Application check
stored_id  = "f29c6ab1..."
derived_id = "f29c6ab1..."

accepted = (stored_id == derived_id)
Another example

Evaluate the real-world precision of one embedding model.

Run one model over a labeled dataset, sweep strictness, and measure the actual match behavior you get in production terms.

1
Labeled dataset

Start with a known pair

Take two samples whose ground truth you already know, for example same person or different person, and embed them with the model you want to evaluate.

Request
POST /v1/bind
{
  "embedding": [0.23, -0.61, 0.08, 0.74, ...],
  "strictness": 0.55
}
Response
{
  "anchor": "0091bc4d...",
  "id": "8a14d02f...",
  "dim": 768,
  "strictness": 0.55
}
2
Model outcome

Check whether the pair matches

Bind the first sample, derive from the second, and compare IDs. Repeat that process across positive and negative pairs to see how the model really behaves.

Request
POST /v1/derive
{
  "embedding": [0.19, -0.59, 0.11, 0.71, ...],
  "anchor": "0091bc4d..."
}
Response
{
  "id": "8a14d02f..."
}
3
Your application logic

You compute precision metrics for that model

Each pair gives you a ground-truth label and an exact-match result. Sweep strictness: if the model keeps good precision at higher values, the embeddings are strong; if accuracy falls apart early, the model is weak for that task.

Evaluation summary
{
  "model": "face_encoder_v1",
  "strictness": 0.55,
  "pairs_evaluated": 10000,
  "precision": 0.972,
  "false_accept_rate": 0.004,
  "false_reject_rate": 0.024
}
Another example

User-profile deduplication, even when the text is not identical.

Use text embeddings from forms, bios or profile fields to decide when two slightly different records still describe the same person.

1
First profile

Bind one version of the user profile

You embed the first form or profile record, then bind it once to get a stable anchor and ID for that entity.

Profile text before embedding
{
  "name": "John Doe",
  "title": "Product Manager",
  "company": "Acme",
  "city": "New York"
}
Request
POST /v1/bind
{
  "embedding": [0.07, -0.42, 0.58, 0.11, ...],
  "strictness": 0.55
}
Response
{
  "anchor": "00af92bd...",
  "id": "7be31fd0...",
  "dim": 768,
  "strictness": 0.55
}
2
Similar record

Derive from a slightly different version

A second record may not be textually identical, but if it describes the same person, the derived ID can still match.

Profile text before embedding
{
  "name": "John A. Doe",
  "title": "Product Lead",
  "company": "Acme Inc.",
  "city": "New York, NY"
}
Request
POST /v1/derive
{
  "embedding": [0.05, -0.39, 0.60, 0.13, ...],
  "anchor": "00af92bd..."
}
Response
{
  "id": "7be31fd0..."
}
3
Your application logic

You resolve whether both records are the same entity

If the IDs match, your application can treat both records as the same underlying entity even when the raw text differs slightly.

Resolution result
{
  "record_a": "crm_1021",
  "record_b": "lead_8874",
  "strictness": 0.55,
  "same_entity": true,
  "action": "merge"
}
About the strictness param in bind

One dial. Three very different operating modes.

strictness is the parameter you send to the API to decide how selective matching should be. The default is 0.5, which is usually the right starting point for production.

Use the playground on RapidAPI to test different strictness values against your own embeddings before you ship.

Open the Playground →
Interactive explainer

Default to 0.5 unless you have hard evidence to move away from it.

Current strictness
0.5
Lenient Balanced Exact
Sweet Spot 0.5 is the default operating point.

Enough tolerance for noisy embeddings. Enough selectivity to keep different sources apart.

False accept risk: balanced False reject risk: balanced
Low strictness 0.00–0.34

Too permissive for most production auth.

Good if you deliberately want broad grouping, risky if you need identity-grade separation.

Balanced zone 0.35–0.65

Where most real deployments should start.

Enough tolerance for noisy embeddings. Enough selectivity to keep different sources apart.

High strictness 0.66–1.00

Very selective and easy to overtune.

Useful only if your encoder is exceptionally stable and you have evidence that aggressive selectivity improves outcomes.

Why teams want this

Embeddings are probabilistic. Applications often need determinism.

The exact same source will not emit the exact same vector every time, so perfect determinism is not free. If you always sent the exact same embedding, you would not need this product in the first place.

What teams usually want is a simpler operating model.

Instead of score thresholds, nearest-neighbor infrastructure and repeated comparison logic, IdemAPI gives you a deterministic ID flow. The strictness parameter controls how precisely embeddings must match: lower values accept more variation, higher values demand near-exact similarity.

Skip the threshold-tuning loop and try the exact bind-then-derive workflow directly from RapidAPI.

Try the API Now →
Quickstart

Two REST calls.

Access idemapi through RapidAPI. Use the host and subscription headers provided by your RapidAPI listing, then call /v1/bind and /v1/derive from there.

Get your API key and start making requests in minutes.

Open idemapi on RapidAPI →
1

Bind

Send one embedding. Store the returned anchor and id.

bash
curl -s -X POST "https://YOUR_RAPIDAPI_HOST/v1/bind" \
  -H "X-RapidAPI-Key: YOUR_RAPIDAPI_KEY" \
  -H "X-RapidAPI-Host: YOUR_RAPIDAPI_HOST" \
  -H "Content-Type: application/json" \
  -d '{"embedding": [0.12, -0.54, 0.87, 0.33, -0.21, 0.66, -0.90, 0.44], "strictness": 0.55}'

# { "anchor": "0008a3f9...", "id": "f29c...", "dim": 8, "strictness": 0.55 }
2

Derive

Send a fresh embedding plus the stored anchor. Compare the returned id to the one you already saved.

bash
ANCHOR="YOUR_ANCHOR_FROM_BIND"
NEW_EMBED='[0.11, -0.55, 0.85, 0.30, -0.23, 0.68, -0.88, 0.42]'

curl -s -X POST "https://YOUR_RAPIDAPI_HOST/v1/derive" \
  -H "X-RapidAPI-Key: YOUR_RAPIDAPI_KEY" \
  -H "X-RapidAPI-Host: YOUR_RAPIDAPI_HOST" \
  -H "Content-Type: application/json" \
  -d "{\"embedding\": $NEW_EMBED, \"anchor\": \"$ANCHOR\"}"

# { "id": "f29c..." }  # compare to your stored id on your side
API errors

Common failures to handle.

The quickstart above is enough for integration. These are the main request errors you may want to surface or log.

Want to see real responses instead of reading tables? The RapidAPI playground is the fastest way to test requests and inspect errors.

Test Requests Live →

Error reference

HTTPMessageCause
401UnauthorizedMissing or invalid RapidAPI authentication headers
400embedding must not be emptySent []
400strictness must be between 0.0 and 1.0strictness out of valid range
400anchor is not valid hexCorrupted or truncated anchor string
400Dimension mismatchDerive embedding has different dim than bind
413—Embedding exceeds 32 768 dimensions
Security properties

Privacy properties for noisy embeddings.

The main operational properties teams usually care about in production.

Explore the API, docs, and examples from the public RapidAPI listing and start integrating immediately.

Use idemapi via RapidAPI →
UL

Unlinkability

Re-enrolling the same source generates fresh material, which makes cross-database linking much harder.

Distinct anchors across rebinds
IR

Irreversibility

The original embedding is not stored, and the anchor alone is not meant to serve as a recoverable template.

Original embedding not retained
NX

No exact-match brittleness

Close embeddings from the same source can still derive to the same ID even when exact hashing would split them apart.

Built for noisy observations
SL

Stateless API

The server stores nothing between calls. No session state, no template DB and no embedding retention on the API side.

Zero server-side storage
RV

Revocable

If material is ever exposed, bind again and issue a fresh anchor/id pair instead of replacing your encoder stack.

Rebind to rotate