上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
APIキーを3つの異なる方法で送る（そしてそれが重要な理由）
APIとやり取りするツールがすべて同じ方法で認証を扱うわけではありません。そのため、このAPIはすべてを1つのヘッダー名に強制するのではなく、複数の仕組みでキーを受け付けています。
X-API-Keyヘッダー
これは最も直接的な方法で、キーだけを運ぶ専用のヘッダーです。
GET /v1/forward?q=Baker+Street
X-API-Key: mg_live_examplekey123Authorization: Bearer
一部のHTTPクライアントやAPIゲートウェイは、送信するすべてのリクエストにBearerトークンを付けるようにすでに設定されています。その仕組みを使えば、API固有の2つ目のヘッダーを並べて追加する必要はありません。
GET /v1/forward?q=Baker+Street
Authorization: Bearer mg_live_examplekey123HTTP Basic認証
古いツールや、他のプロバイダー向けに作られた一部のサーバー間連携では、認証情報がHTTP Basic認証で渡されることを想定しています。キーをユーザー名として入れ、パスワードは空欄のままにします。
GET /v1/forward?q=Baker+Street
Authorization: Basic bWdfbGl2ZV9leGFtcGxla2V5MTIzOg==それ以外のすべての場合はクエリパラメータ
ブラウザのアドレスバーでの簡単なテストや、URLベースの設定しかサポートしないクライアントのように、ツールでヘッダーをまったく制御できない場合は、キーをクエリパラメータとしてリクエストに直接渡すこともできます。
GET /v1/forward?q=Baker+Street&key=mg_live_examplekey123実際にこの選択が重要になる理由
クエリパラメータとして送信したキーは、リクエストヘッダーで送信したキーよりも、サーバーログ、ブラウザの履歴、リファラーヘッダーに残りやすくなります。そのため、呼び出し側のコードで少しでも制御できる場合は、ヘッダーベースの方法を選んでください。4つの方法はすべて、どのエンドポイントとどの互換ホストでもまったく同じように動作します。そのため、たとえばスクリプトをブラウザでのテストから本格的なバックエンド連携に移行するときなどに、後から方法を切り替えても、キーに対する割り当てやクレジットの集計方法は何も変わりません。
互換ホストでの利用
17個の互換ホストはどれも、元のプロバイダーが使っていたのと同じ形式で認証情報を受け付けます。そのため、他のプロバイダーの認証方式に合わせて書かれたスクリプトは、対応するMy Geocodeの互換ホストに向け先を変えた後も、キーの送信方法を書き換えることなく、たいていそのまま動作します。ホストの一覧と、それぞれが想定する認証情報の形式については、互換性のページをご覧ください。
避けるべき間違い
キーをクエリパラメータにしてスクリプトをテストし、そのまま本番環境でも使い続けてしまうのは、身につきやすい習慣です。クエリパラメータは、最初のリクエストを動かすための最も手早い方法であることが多いからです。スクリプトを本番トラフィックに近づける前、または共有リポジトリにチェックインする前に、ヘッダーベースの方法（X-API-KeyまたはAuthorization）に切り替えてください。URLに表示されるキーは、プロキシのログや共有マシン上のブラウザ履歴ファイルなど、意図しない場所に残ってしまう可能性がはるかに高いためです。
コストの違いはありません
これらの方法のどれを使っても、リクエストの課金方法は変わりません。キーに対するすべてのリクエストは、1日あたり2,500件の無料リクエストに対して同じように集計され、それを超えるとプリペイドクレジットまたはUnlimitedパッケージから差し引かれます。
適切な認証方法を選ぶことは、パフォーマンスやコストの問題ではなく、主に呼び出し側のツールがすでにサポートしているものに合わせることです。詳しくは認証のドキュメントをご覧ください。