Twitter APIを使用する上でのハマりポイント

概要

TypeScriptでTwitter APIを使用する際にハマりやすいポイントを紹介します。TypeScriptじゃなくてももしかしたら有効かもしれません。

環境

TypeScript 4.1.3

ハマりポイント

Developer Portalの設定

①App permissionsをReadのままにしている

Botを作っているときに、401エラーが出たら大体これです。App permissionsをRead and Writeにしましょう。DMを送る場合はRead and Write and Direct Messagesにする必要があります。また、これらの変更を行なったら必ずKeys and tokensからAccess Token and Secretを再発行してください。再発行しないと変更が反映されません。Created with *** permissionsと書いてあるので、そこを見れば現在のpermissionsが確認できます。

②CALLBACK URLSを設定していない

Authentication settingsのCALLBACK URLSは必ず設定する必要があります。Webアプリの場合は認証後にリダイレクトされるURLを設定します。ただのBot運用の場合はあまり気にする必要はないと思います。ただし、架空のURLなどは弾かれるので、自分の環境にあったURLを設定するのが無難です。

型定義をインストールしていない

TypeScriptでライブラリを使用する際に困りがちなのが型定義だと思いますが、npmのTwitterにもちゃんと型定義が存在します。@types/twitterとtwitter-dをインストールしましょう。

npm i @types/twitter --save-dev

npm i twitter-d --save-dev

リプライを送るBotでPOST statuses/updateのパラメータの記述を間違っている

APIを通してツイートをする際はPOST statuses/updateを使用しますが、エラーが出る場合はパラメータがミスってる可能性が高いです。

①auto_populate_reply_metadata

Twitter APIの日本語リファレンスとしてとても有用なSyncer様ですが、こちらに記載の無いパラメータが存在します。それがauto_populate_reply_metadataです。このパラメータはデフォルトがfalseで、trueにするとリプライ先の@***の情報(ユーザ情報のメタデータ)を自動で付与してくれます。ですので、「あるツイートのリプライ」にリプライする場合など、リプライ先のユーザ情報が多い場合はtrueにしておくと楽になります。ただし、すべてを巻き込んでリプライする形となるので、「リプライ先のリプライ先」に通知を送りたくない場合はfalseにした方がいいです。


ややこしくなったのでまとめます。

falseの場合

返信先は、あくまでもin_reply_to_status_idに指定したツイートのユーザひとりだけです。

trueの場合

返信先には、in_reply_to_status_idに指定したツイートのユーザだけでなく、そのツイートがさらに他のツイートのリプライだった場合そのリプライ先のユーザも返信先に含まれます。

②in_reply_to_status_idにnumber型のidを指定している

リプライを送ろうとして385エラーが出ている場合、in_reply_to_status_idがミスってる可能性が高いです。基本的にリプライを送る際はその前にGET statuses/mentions_timelineやGET search/tweetsでツイートを取得すると思いますが、その際にツイートのid_strではなくidを取得してはいけません。idは桁数が多すぎて桁落ちしてしまっているので、id_strを取得しましょう。そして、in_reply_to_status_idにもstring型をそのまま指定してください。わざわざparseInt()などでnumber型に変換する必要はありません。