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

Algolia supports zero-downtime reindexing by copying records to a temporary index and then using the move-index operation to swap it into production. For a small application, this pattern avoids service interruption, but it exposes a permission boundary when clients use restricted API keys. Keys scoped to a specific index name—including secured API keys generated with restrictIndices—remain bound to the original index name after the move. Because Algolia does not provide index aliases, there is no native indirection layer to keep those credentials valid against the new physical index name.

The copy operation is asynchronous and does not guarantee a point-in-time snapshot if writes continue to the source index, so the migration window introduces additional consistency concerns. Before cutover, the application must decide how to handle credentials that reference the old index name, especially since previously issued secured API keys cannot be updated server-side and must be regenerated if the index name changes.

What is the recommended configuration for scoping new API keys to the target index before the move while ensuring old keys are retired only after all traffic has cut over? How should dual-writing during the copy window be coordinated with key rotation to avoid authorization gaps? Is there a documented way to verify that every existing key’s indexes field no longer references the released old index name before the move completes?