Algolia move-index operation leaves restricted API keys bound to original index name

Answer

Pre-create new restricted API keys scoped to the target production index name before you call move-index, keep the old keys active during the copy window, and retire the old keys only after server-side logs confirm zero traffic using them. Dual-writes must be performed with a server-side key that can write to both source and temporary indexes. A complete pre-move inventory of all secured API keys is not possible in Algolia; verification relies on listing application-level restricted keys and client-side telemetry.

Confirmed facts

• Algolia restricted API keys are immutable and bound to explicit index names at creation time. The indexes field cannot be changed after issuance.
• Secured API keys generated with restrictIndices inherit the parent key's restrictions and are immutable after issuance. They cannot be updated server-side.
• move-index replaces the destination index with the source and removes the source index name. Any credential that references the source name becomes invalid after the move.
• Algolia does not provide index aliases for indirection.
• Copy operations are asynchronous and do not guarantee point-in-time consistency if writes continue to the source index during copy.

Likely explanation for the permission boundary

Because keys are bound to index names, a move changes the physical name that clients are allowed to access. There is no alias layer to keep old credentials working against the new physical index. Secured keys issued to clients remain tied to the names encoded at generation time.

Recommended configuration for safe cutover

1. Create new application restricted API keys scoped to the target index name before the move. Do not replace the old keys yet.
2. If dual read access is required during transition, create a temporary restricted key that lists both the old source name and the new target name in its indexes field. Use this only for the migration window.
3. Keep existing client keys active until traffic has been confirmed to use the new keys.
4. Retire old keys only after logs show zero search and analytics requests using them for a defined observation period.

Dual-write coordination with key rotation

• Writes during the copy window should be performed with a server-side admin key that has access to both source and temporary index.
• Migrate client read traffic gradually to keys scoped to the target name while old keys remain valid.
• Quiesce writes to the source index, complete the copy, then execute move-index from source to destination.
• Rotate client keys only after the move is complete and new keys are confirmed working against the target name in production.

Verification limits

Algolia does not provide a central inventory of all issued secured API keys. Application-level restricted API keys can be listed via the API Keys API and inspected for references to the soon-to-be-released source index name.

Practical verification steps:

• List application restricted keys and inspect the indexes field for the old source name.
• Monitor search and analytics logs for 403 authorization errors and traffic volume per key before retiring old keys.
• Validate new keys succeed against the target name in a staging environment before cutover.
• Track client adoption of new keys via server-side request logging to ensure zero traffic remains on old keys before retirement.

Complete pre-move verification of every active secured key is not possible without client-side telemetry, because client-generated secured keys cannot be enumerated centrally.

Missing diagnostic detail

Are secured API keys generated server-side per session or baked into client applications? If they are baked into clients, rotation requires a client release and the cutover plan must include a longer overlap window and feature flag.