Performance
Prefer bulk endpoints (/tokenize/bulk, /detokenize/bulk, or the SDK bulk helpers). One bulk call for many fields is far cheaper than the same number of single calls, both in latency and in rate-limit budget.
Hard limits
| Limit | Value |
|---|---|
| Fields / tokens per bulk request | 1 000 |
| Rate limit per API key (tokenize / detokenize / lookup) | 1 000 HTTP calls / minute |
| Shred / shred-bulk per API key | 100 HTTP calls / minute (up to 1 000 tokens per shred-bulk call) |
| Gateway default batching | 1 000 fields/call, 4 calls in flight |
Dashboard quotas count request units (1 bulk field = N units). Rate limits count HTTP calls.
Indicative results (SaaS · 3.0.3)
Wall-clock latency from an EU client to https://app.veilio.fr/api (includes network).
| Scenario | p50 | p95 |
|---|---|---|
| Tokenize 1 field | 222 ms | ~270 ms |
| Detokenize 1 token | 186 ms | ~210 ms |
| Lookup | 218 ms | — |
| Tokenize bulk 1 000 | 1.5–2.6 s | — |
| Detokenize bulk 1 000 | 0.3–0.5 s | — |
| Tokenize, 10 in parallel | 20 calls/s | p95 524 ms |
| Detokenize, 10 in parallel | 20 calls/s | — |
| Dataset import 1 000 rows (API key) | 5.6 s | — |
| Dataset download 1 000 rows (API key) | 0.7–1.1 s | — |
| Shred 1 token | 190 ms | — |
Takeaways
- A screen that reveals 10 fields with 10 single calls costs ~2 s on SaaS. The same work as one
detokenize/bulkis ~0.3 s. - Bulk of 1 000 fields is the right import pattern.
- SDK JS / Python match HTTP latency (thin clients).
Indicative results (on-premise · veilio/app:3.0.3)
Same machine as the Hub (local RTT). Reads stay local; writes still pay vault + durable storage.
| Scenario | p50 |
|---|---|
| Tokenize 1 field | 47 ms |
| Detokenize 1 token | 41 ms |
| Lookup | 48 ms |
| Tokenize bulk 100 | 71–88 ms |
| Tokenize bulk 1 000 | 0.3–0.4 s |
| Detokenize bulk 1 000 | 77–104 ms (one call) |
| Tokenize, 10 in parallel | 38 calls/s (p95 ~360 ms) |
| Detokenize, 10 in parallel | ~50 calls/s |
| Dataset import 1 000 rows (API key) | ~1.0 s |
| Dataset download 1 000 rows (API key) | ~0.26 s |
| Shred 1 token | ~20 ms |
| Shred-bulk 50 tokens (session or API key) | ~0.7 s |
| Gateway INSERT (4 protected fields) | ~86 ms |
| Gateway SELECT list of 100 with clear fields | ~124 ms |
| Gateway unprotected table | ~1 ms (TCP_NODELAY on current Gateway) |
Takeaways
- On-prem tokenize stays fast even on large API keys (append-only stream dataset; no per-call grid rewrite).
- Prefer bulk the same way as SaaS.
- Measure again from your host before go-live.
Capacity planning
- Count protected fields written per minute at peak (not total rows)
- Prefer bulk so HTTP calls ≈
ceil(fields / 1000), notfields - Stay under 1 000 calls/min/key
- For Gateway list screens, plan a reveal cache/relay or staggered refreshes
- Paste your own p95 into the runbook