こんにちは。
該当のスクリプトをざっと見てみましたが、
構造的には、"if totalUsers > 4000:"とすれば、最大4000ユーザまで削除する意味になります。
動きとしてはCSVで指定できるユーザ数がこのif文で制限されています。
仕組みとしてはCSVを読み込んで、
emailをキーにユーザ情報を取得(GET /v1/people)して、削除する(DELETE /v1/people/{id})を繰り返しているだけになります。
処理の効率性はそれほど考慮された実装ではないので、4000件処理するのには、
かなりの時間がかると思います。
順調に進んでも２時間から３時間くらいはかかるんじゃないかと思います。
HTTPレスポンスの429の処理が、「とりあえず３０秒待つ」になっているので、
HTTPレスポンスコードの429を受信するようなケースが多くなると、
その分、処理時間がどんどん長くなると思います。
リクエストが多すぎると、APIサーバー側で動的な判断でリクエストを受け付けなくなり、
429エラーとなって、"Retry-After"ヘッダーで待つべき秒数を返す仕組みになっています。
動的な処理なので、具体的にどのくらいこのエラーが発生するかは予測が難しいです。
また、エラーは429しか処理していないので、その他のエラー発生時は、
エラー用のファイルに書き込み仕組みになっているので、スクリプトを動かした後に、
エラーファイルを検証して、そのユーザだけ再度削除を試みるかの検討が必要かと思います。
エラーファイルを見て、エラーコードが404だったら、その項目は無視してもいいと思います。
(ユーザがすでに存在しないのに削除しようとした意味になります。)
効率性を追求した実装になっていないとか、エラー発生時の処理も理想的ではないということを理解したうえで、
運用上、単発的に活用するのであれば、特に問題ないかと思います。
"https://api.ciscospark.com/"というAPIのパスがちょっと古くて、まだ使えるのですが、
"https://webexapis.com/"に変えてもいいかもしれません(動きは変わらないはずですが)。
WebexのAPIとは異なる理由で落ちる可能性もあるので、その場合は柔軟に対応する必要が出てくるかもしれません。
処理中に利用しているライブラリ内部から例外が送出される可能性とか、
CSV関連の処理でメモリ系の問題が発生するなどの可能性も一応あります(4000件程度なのでメモリ的には普通は問題ないと思っています)。
該当のスクリプトに関しては、サポートが提供されるものではないのですが(フッターにDiscrimerがあります)、
コミュニティでは気軽に相談いただいて構いません。
対応はベストエフォートとなります。
