Tenant-isolated Algolia search with per-user secured API keys

Problem: search without leaking admin access or tenant data

You need low-latency full-text search for a multi-tenant product, but shipping an Algolia admin or even a broad search-only key to the browser is unacceptable. The useful takeaway is to keep all privileged credentials server-side and mint short-lived secured search keys per request that embed a tenant filter. The client can only query what the backend explicitly allows for that user.

Requirements that drive the design

Low-latency search from the browser with no admin key exposure. Tenant isolation must be enforced at search time, not only in application logic. Keys must be revocable in practice via short TTLs. The index is a read-optimized copy, not the system of record.

Algolia secured API keys let a server sign a search-only key with restrictions such as allowed filters, validUntil timestamp, and query parameters. The design relies on that capability plus server-side token minting.

Smallest suitable design

Backend holds the admin API key. The client never sees it. On each search session or request the backend generates a secured key bound to the caller.

Example minting in a backend service. Run in your API process, not in client code. Requires environment access to ALGOLIA_APPLICATION_ID and ALGOLIA_ADMIN_KEY. Risk: logging the admin key or the secured key leaks scope for the TTL.

// backend, e.g., Node.js service
// Requires: ALGOLIA_ADMIN_KEY with key generation permission
// Placeholders: user.tenantId, user.id
const client = algoliasearch(appId, adminKey);
const searchOnlyKey = process.env.ALGOLIA_SEARCH_KEY; // search-only, no admin rights

const securedKey = client.generateSecuredApiKey(searchOnlyKey, {
  filters: `tenantId:${user.tenantId}`,
  validUntil: Math.floor(Date.now()/1000) + 300,
  userToken: user.id
});
return { securedKey };

The client uses the returned secured key for Algolia search calls. The filter is enforced by Algolia; the client cannot remove it. Keep TTL short, e.g., minutes, to limit blast radius if leaked.

Index records must contain a tenant identifier attribute, e.g., tenantId, that is indexed and never mutable by the client. Writes to the index happen server-side only, using the admin key.

Trust and data boundaries

Trust boundary one is application backend to Algolia SaaS. The backend is trusted to mint correct filters and to hold the admin key. The client is untrusted.

Data in transit is TLS protected by Algolia. Data at rest is managed by Algolia. Treat the index as a denormalized, eventually consistent view. Do not store sensitive PII without classification and minimization, because the index is optimized for search and may be replicated.

Secured keys are scoped but not a full authorization layer. They restrict search parameters, not business rules beyond search.

Operational checks

Monitor search latency p95, error rate, query volume versus plan rate limits, index size growth, and token generation latency in the backend.

Alert on spikes in rejected queries, increased 429 responses, or anomalies in filter usage that may indicate misconfiguration or abuse. Compare Algolia dashboard metrics to baseline SLAs after rollout.

Validate filters in automated tests and staging. A syntax error in the filter string can broaden results. Test token generation in a non-production environment by issuing queries with valid, expired, and tampered tokens and confirming tenant filter enforcement.

Failure modes

Leaked secured key enables abuse within its TTL and filter scope. Mitigation is short TTLs and least-privilege filters.

Admin key compromise grants full index access. Mitigation is secret management, rotation, and restricting admin key usage to server environments only.

Filter misconfiguration leaks cross-tenant data. Mitigation is automated validation of filter construction and review of index schema changes.

Algolia service degradation reduces search availability. The application should treat search as best-effort and degrade gracefully, falling back to backend queries if required.

When the design should change

Consider per-tenant indexes or separate Algolia applications if requirements shift to cross-tenant search controls, strict data residency, or regulated PII with different retention needs.

Client-side writes, the need for fine-grained field-level security, or requirements for stricter network controls would push authorization back into the backend and away from filter-based isolation.

Limitations and verification

Filter-based isolation depends on correct filter construction. Algolia indexing is eventually consistent and best-effort; do not use it as source of truth for transactional data.

Review Algolia API key restriction concepts for search-only keys and secured key parameters such as filters and validity. Monitor the dashboard after rollout and confirm tenant isolation holds under realistic query patterns.