AACSearch
Erste Schritte

Plattformüberblick

Wie AACSearch Mandanten, Indizes, API-Schlüssel und Abrechnung organisiert und was auf dem Pfad eines Requests passiert.

AACSearch stellt verwaltete Suche über Konsole, REST-API und SDKs bereit. Sie adressieren Indizes über ihren logischen Slug; interne Speichernamen und Infrastruktur-Zugangsdaten verwaltet die Plattform.

Organisationen und Indizes

Eine Organisation besitzt ihre Indizes. Jeder Slug ist innerhalb der Organisation eindeutig — es gibt keine separaten Staging- oder Development-Kopien desselben Slugs. API-Schlüssel können auf einen Index und eine Menge von Scopes beschränkt werden. Jede Anfrage prüft diesen Geltungsbereich und den Dokumentzugriff, bevor Ergebnisse zurückgegeben werden. Organisationsrollen bestimmen den Zugriff auf private Felder.

Schemaänderungen werden geplant und bei Bedarf im Hintergrund neu aufgebaut. Der veröffentlichte Index wechselt erst nach Fertigstellung der neuen Version. Clients verwenden weiterhin denselben logischen Slug.

Anatomie eines Index

Diese Felder legt die Plattform in jedem neuen Index an:

FeldTypHinweis
external_idstringIhre ID; eindeutig innerhalb des Index
titlestring, optionalTeil des Standard-query_by
contentstringIn jedem Dokument erforderlich
urlstring, optional, nicht indiziertZiel des Treffers
source_typestring, Facetteapi, webhook, connector und ähnliche
organization_idstring, FacetteMandanten-Scope, von der Plattform gesetzt
tagsstring[], Facette, optionalGünstige Facetten und Filter
indexed_atint64Standard-Sortierfeld
metadatastring, optional, nicht indiziertFreies JSON, gespeichert, nicht durchsuchbar

Eigene Felder legen Sie beim Anlegen fest: string, string[], int32, int64, float, bool, geopoint, reference, object, float[] (Vektor) und auto. Felder können facettierbar, sortierbar, optional, Infix-indiziert, locale-bewusst sein oder einen embed-Block für Auto-Embedding tragen.

Pfad einer Suchanfrage

  1. Der Schlüssel wird aus Authorization: Bearer aufgelöst — Hash-Lookup, widerrufene Schlüssel scheitern, Scopes und optionale Indexbindung werden geladen.
  2. Das Rate-Limit dieses Schlüssels wird geprüft (gleitendes Fenster, pro Schlüssel).
  3. Der Index wird innerhalb der Organisation des Schlüssels gesucht; ein an einen Index gebundener Schlüssel erreicht dessen Geschwister nicht.
  4. Ein gespeichertes Suchprofil kann Vorgaben setzen, oder ein A/B-Bucket wählt eines.
  5. Tarifkontingent und Tariffunktionen werden geprüft; die Suche wird gezählt.
  6. Die Engine führt die Abfrage mit angehängtem Mandantenfilter aus.
  7. Query, Latenz, Trefferzahl und Null-Ergebnis-Flag werden protokolliert; Klicks und Conversions kommen später über /events dazu.

Schritte 1–6 erklären, warum ein 403 meist ein Scope- oder Tarifproblem ist und kein fehlender Index.

Tarife im Überblick

Die Limits stammen aus dem Billing-Katalog: Free (10.000 Suchen, 1.000 Dokumente, 5 Indizes, 3 Schlüssel), Pro für 29 USD/Monat (500.000 Suchen, 50.000 Dokumente, 10 Indizes, 10 Schlüssel) und Enterprise (individueller Preis, 5.000.000 Suchen, 1.000.000 Dokumente, 100 Indizes). Überschreitungen werden blockweise aus einem Prepaid-Wallet bezahlt; Free kennt keine Überschreitung und stoppt am Limit.

Die exakten Zahlen, Feature-Flags und Blockpreise stehen unter Fehler & Limits und Kontingente & Abrechnung.

Indizes und Schlüssel verwalten

Die REST-API unterstützt das Anlegen von Indizes mit einem Organisationsschlüssel mit indexes:write. Ein indexgebundener Schlüssel kann keine weiteren Indizes anlegen. Schemaänderungen durchlaufen Validierung und Migrationsplanung; für einen Neuaufbau wird ein Hintergrundauftrag zurückgegeben. Schlüsselzugriffe verwalten Sie in der Konsole; die erforderlichen Scopes stehen in der OpenAPI-Referenz.

On this page