在结账前核对地址与所填邮政编码是否一致
订单表单上邮政编码与城市不一致，看起来只是个小笔误，直到包裹被送到国内完全不同的地方。
为骑行应用构建海拔剖面图
规划路线的骑行者最关心的一个数字是：需要爬升多少。平坦的四十英里和起伏的四十英里完全是两种不同的骑行，一款为路线规划而打造的骑行应用需要在骑行者决定出发之前就展示出这种差异，而不是等到他们爬过三座山坡后才后悔。
该应用已经拥有由坐标序列构成的路线，由其自身的路线引擎根据起点和终点生成。它缺少的是每个点的海拔。/v1/elevation 直接解决了这个问题：向它发送一组坐标，无论是单个点还是沿路线的一长串点，它都会返回每个点的地面海拔。一条沿途有两百个点的路线会返回两百个海拔值，顺序与发送时一致，可以直接按行进距离绘制成剖面图。
把这组数据按累计距离绘制成图表，就是骑行者真正想看的爬升图：哪里有山坡，与相邻各点相比上坡看起来有多陡，平路在哪里。该应用用它来计算路线的总爬升高度，结果发现，对于决定是否挑战一条路线的骑行者来说，这个单一数字比总距离更重要。
由于一条路线根据长度可能有几十到几百个点，而且批量海拔请求中的每个点都按一个计费项计算，该应用调整了每条路线的采样点数，而不是为每次骑行都以最精细的分辨率请求海拔。一条平缓的路线每隔几百米采样一次，得到的剖面图与每隔十米采样一次同样有用，请求量却只是后者的一小部分，而且骑行者在查看最终图表时根本看不出区别。
该应用还允许骑行者按需查询单个点：点按地图上的任意位置，即可查看该精确位置的海拔，这使用的是同一个端点，只是请求中只有一个点，而不是整条路线。单点和批量两种情况都通过同一个调用完成，使应用代码保持简洁：一个函数接收一组坐标，返回对应的一组海拔，既用于快速点按，也用于完整的路线规划。
流量随骑行者规划的路线数量增长，而不是随他们实际骑行的次数增长，因为一条已保存的路线只需计算一次剖面图。对于一个用户活跃但规模不算庞大的应用来说，这使海拔查询稳稳处在每日免费配额之内；如果某个受欢迎的新功能带来路线规划的激增，预付额度就是自然的下一步。
海拔是少数几个很容易举出真实例子的端点之一：一条沿海骑行路线在起始部分的海拔值接近海平面，随着路线向内陆爬升，海拔值不断升高，骑行者一眼就能看懂这张图表的含义。请求格式和点数限制的详细信息见 /docs/elevation-lookup/。