在达到限制之前监控密钥用量
随时关注配额响应头，就能在请求真正被拒绝之前，提前知道何时即将达到限制。
用三种不同方式发送您的 API 密钥（以及为什么这很重要）
并不是每个与 API 通信的工具都以相同的方式处理身份验证，这就是为什么 API 通过不止一种机制接受密钥，而不是强制所有请求都使用同一个请求头名称。
X-API-Key 请求头
这是最直接的方式，一个只携带密钥的专用请求头。
GET /v1/forward?q=Baker+Street
X-API-Key: mg_live_examplekey123Authorization: Bearer
有些 HTTP 客户端和 API 网关已经设置为在每个发出的请求上附加 Bearer 令牌，使用这种机制意味着您无需再额外添加一个 API 专用的请求头。
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为什么这个选择在实践中很重要
作为查询参数发送的密钥，比放在请求头中发送的密钥更容易出现在服务器日志、浏览器历史记录和 Referer 请求头中，因此只要调用代码能控制，就请优先使用基于请求头的方式。这四种方式在每个端点和每个兼容主机上的效果完全相同，因此以后在它们之间切换，比如把脚本从浏览器测试迁移到正式的后端集成时，密钥的配额或额度的计算方式不会有任何变化。
在各兼容主机上使用
17 个兼容主机中的每一个都以原服务商所用的相同方式接受凭据，因此按照其他服务商的身份验证约定编写的脚本，在指向对应的 My Geocode 兼容主机后，通常可以继续工作，无需重写发送密钥的方式。主机列表以及每个主机要求的凭据方式，请参阅兼容性页面。
值得避免的错误
测试脚本时把密钥作为查询参数，然后在生产环境中原样保留，这是一个很容易养成的习惯，因为查询参数往往是让第一个请求跑通的最快方法。在脚本接触生产流量或被提交到共享代码仓库之前，请改用基于请求头的方式，即 X-API-Key 或 Authorization，因为出现在 URL 中的密钥更有可能落到您意想不到的地方，比如代理日志或共享机器上的浏览器历史文件。
费用没有差别
这些方式都不会改变请求的计费方式。使用该密钥的每个请求仍然以同样的方式计入其每天 2,500 次免费请求，超出后则从预付额度或 Unlimited 套餐中扣除。
选择合适的身份验证方式，主要在于匹配调用工具已经支持的方式，而与性能或费用无关。完整详情请参阅身份验证文档。