Launch checklist

Run this before pointing real traffic at AACSearch. Each section ends with a check that answers a specific question; if a check fails, fix it before moving on.

Data

• Import representative documents with stable ids from your own catalogue, not generated ones.
• Inspect rejected rows — an accepted batch can still contain per-row failures. See incremental indexing.
• Verify updates and deletions, not only the initial load.
• Check field types, facet flags, searchable fields and sort behaviour against what your UI actually needs.
• Keep your source data, and prove you can rebuild the collection from it.

Check: update one document, search for the new value, then delete it and confirm it stops appearing. This proves writes and deletes both reach the index.

Access

• Full keys exist only on your server. Nothing in a browser holds one.
• Browser clients use a search key, ideally a short-lived one minted with createBrowserKey. See keys and the widget.
• Search keys are restricted to the collections they should reach.
• Allowed origins and IPs are set for browser keys, and the production origin is among them.

Check: call an operation outside a search key's scope and confirm it answers 403 rather than succeeding. A search key that can create a collection is misconfigured.

Search experience

• Test exact queries, typos, empty queries and zero-result queries.
• Test on mobile and desktop, including keyboard navigation and filter clearing.
• Loading and error states are visible to the visitor, not silent.
• Publish a search profile if the storefront should not send raw query_by/facet_by.
• Confirm visitors are served the active release, not your draft.

Check: edit the profile draft and confirm live search is unchanged, then publish and confirm the change takes effect. Then activate an older release and confirm the previous sorts and facets come back.

Billing and quota

• The organization is on the intended plan.

curl https://api.aacsearch.com/v1/entitlement \
  -H "X-NOVA-API-KEY: $NOVA_API_KEY"

• features contains everything you call. Anything missing will answer 403 in production.
• The wallet has credits if you use assistant, voice, image, semantic or reranked search.
• You know what happens at zero: keyword search keeps working, metered AI features answer 402.

Check: the response's plan is the plan you bought, suspended is absent or false, and quota shows the expected ceiling. See plans, usage and credits.

Operations

• Webhooks you need are registered, the signature is verified end to end, and a deliberately failing endpoint is retried.
• Your client honours Retry-After and backs off on 500/502/503.
• Retried writes are safe: Idempotency-Key on createConnector, event_id on events, and deduplication for webhook deliveries.
• A baseline of useful queries is recorded before you change relevance.
• Use experiments if you split traffic.
• Production secrets and payment bindings are verified in the production environment — a local test is not a live-payment acceptance test.
• It is written down who can publish relevance, rotate keys and respond to an incident.

Check: trigger a failing webhook delivery on purpose and confirm the delivery record shows retries, then confirm your receiver deduplicates by X-AACSearch-Delivery.

Recovery

• You can reconstruct every collection from source data.
• The owner account is recoverable: two-factor backup codes are stored, and a second owner or admin exists.
• You know the incident path: the support inbox and what information to include.

Check: confirm a second person can sign in with an administrative role, and that at least one person besides the original owner holds ownership.

Next

• Limits and quotas — the ceilings these checks verify against.
• Errors and retries — what to branch on when a check fails.
• Webhooks — event delivery in production.