Platform overview
How AACSearch organises tenants, indexes, API keys and billing, and what each part of the request path does.
AACSearch provides managed search through the console, REST API and SDKs. You address indexes by their logical slug; internal storage names and infrastructure credentials are managed by the platform.
Tenant and index scope
An organization owns its indexes. Each slug is unique within the organization — there is no separate staging or development copy of the same slug. API keys can be restricted to one index and a set of scopes. Each request checks that scope and document access before returning results. Organization roles govern private fields.
Schema changes use a plan and, when required, a background rebuild. The published index switches after the replacement is ready. Clients keep using the same logical index name.
Index anatomy
A new index always contains these fields, created for you:
| Field | Type | Notes |
|---|---|---|
external_id | string | Your identifier; unique inside the index |
title | string, optional | Used by the default query_by |
content | string | Required on every document |
url | string, optional, not indexed | Where the hit points |
source_type | string, facet | api, webhook, connector and similar |
organization_id | string, facet | Tenant scope, injected by the platform |
tags | string[], facet, optional | Cheap faceting and filtering |
indexed_at | int64 | Default sorting field |
metadata | string, optional, not indexed | Free-form JSON, stored but not searchable |
You add your own fields when creating the index: string, string[], int32, int64, float, bool, geopoint, reference, object, float[] (vector) and auto. Fields can be facetable, sortable, optional, infix-indexed, locale-aware, or carry an embed block for auto-embedding.
Request path of a search
- The key is resolved from
Authorization: Bearer— hash lookup, revoked keys fail, the key's scopes and optional index binding are loaded. - The rate limit for that key is checked (sliding window, per key).
- The index is looked up inside the key's organization; a key bound to one index cannot touch its siblings.
- A saved search profile may apply defaults, or an A/B bucket picks one.
- Plan quota and plan features are asserted; the search is metered.
- The engine runs the query with the tenant filter appended.
- The query, latency, result count and zero-result flag are logged; click and conversion events can be attached later through
/events.
Steps 1–6 are the reason a 403 usually means a scope or plan problem rather than a missing index.
Plans at a glance
Limits come from the billing catalog: Free (10,000 searches, 1,000 documents, 5 indexes, 3 keys), Pro at $29/month (500,000 searches, 50,000 documents, 10 indexes, 10 keys) and Enterprise (custom pricing, 5,000,000 searches, 1,000,000 documents, 100 indexes). Overages are charged from a prepaid wallet per billing block; Free has no overage, so it stops at the limit.
The exact numbers, feature flags and block prices are on Errors & limits and Quotas & billing.
Managing indexes and keys
The REST API supports index creation with an organization key carrying indexes:write. An index-bound key cannot create sibling indexes. Schema changes go through validation and a migration plan; changes requiring a rebuild return a job. Use the console to manage key access and the OpenAPI reference for each operation’s scopes.