上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
1日の割り当てを消費せずに連携をテストする
連携を構築するには、通常、本番トラフィックに近づく前に何十回、何百回ものテスト呼び出しが必要になりますが、そのテストのどれにも有料プランを使う必要はありません。
キーをまったく使わずにテストする
どのアドレスからでも、キーをまったく使わずに1日あたり2,500件の無料リクエストを利用できます。これは、リクエストの形式の組み立て、レスポンスの解析の確認、そしてそれぞれいくつかのテストケースでのエラー処理の検証といった、ほとんどの連携作業に十分な量です。
GET /v1/forward?q=Test Address, Test City&limit=1X-API-Keyヘッダーも、Authorizationヘッダーも不要で、必要なのはリクエストそのものだけです。
テスト中に割り当てヘッダーを確認する
キーがなくても、すべてのレスポンスには同じ割り当てヘッダーが含まれているため、X-Quota-UsedとX-Quota-Free-Remainingが本番環境とまったく同じように増減する様子を確認できます。これは、本番で問題になる前に、自分のコードがそれらのヘッダーをどう扱うかをテストするのに役立ちます。
X-Quota-Limit: 2500
X-Quota-Used: 42
X-Quota-Free-Remaining: 2458クレジットを消費せずにキーをテストする
新規登録してキーを発行すると、そのキーにも独自に1日あたり2,500件の無料リクエストが付与されます。これはプリペイドクレジットに影響せず、Unlimitedパッケージの利用分にもカウントされない、独立したテスト枠です。キーの送り方の違い（ヘッダー、Bearerトークン、Basic認証、クエリパラメータ）など、キー固有の動作は、この段階で費用をかけずにテストできます。
エラー経路を意図的にテストする
不正なパラメータを付けてリクエストを送り400を確認したり、わざと誤ったキーを使って401を確認したりすることで、エラー処理のコードが動くと思い込むのではなく、リリース前に実際に動かして確かめられます。こうしたテスト呼び出しは、成功しても失敗しても無料の割り当てから1件のリクエストとして数えられますが、通常のテスト量であれば気にする必要はありません。
本番トラフィックへの移行
実際のトラフィックが始まってからも、多くの小規模な連携では同じ無料の割り当てで日々の一般的な利用量をまかなえます。プリペイドクレジットやUnlimitedパッケージが必要になるのは、利用量が1日2,500件のリクエストを超えてからです。
無料の割り当てだけで本物のAPIを使った本格的なテスト環境がすでに手に入るため、別途サンドボックス環境を用意する必要はありません。ダッシュボードでキーを発行して始めるか、新規登録の前にキーの形式を確認したい場合は、先に認証のドキュメントをお読みください。