API unsupport the channel
錯誤原因
請求的 HTTP Schema 不正確。
不同 API 支援的 HTTP Schama 不同，API 提供者可以自行設定，支援僅 HTTP 訪問、僅 HTTPS 訪問，或者同時支援 HTTP 和 HTTPS。
API unsupport the channel：HTTP，API 只允許 HTTPS 訪問，而發起 API 請求時卻使用了 HTTP，則會得到此提示。
API unsupport the channel：HTTPS，API 只允許 HTTP 訪問，而 API 請求卻使用的是HTTPS，則會得到此提示。
解決方案
API unsupport the channel：HTTP，更換為 HTTPS，發起 API 呼叫。
API unsupport the channel：HTTPS，更換為 HTTP，發起 API 呼叫。
返回A403IS錯誤碼
錯誤原因
用戶端與服務端計算的簽名不匹配導致的問題。
解決方案
當簽名不匹配時網關會通過 HTTP Response Header 中的 X-Ca-Error-Message 返回服務端參與簽名計算的 StringToSign。
StringToSign是使用者請求前需要拼接的一個用於計算簽名的字串，在文檔：【使用摘要簽名認證方式調用API】查看詳細說明。
用戶端只需列印出本地自己拼接的 StringToSign 進行對比，找出哪裡不同，針對性的解決，如果使用的官方提供的調用 Demo，可以到簽名計算的工具類中找出計算簽名前的 StringToSign 列印出來即可進行對比。
因為 HTTP Response Header 中不允許出現分行符號，因此返回結果中的 StringToSign 分行符號都已經被去除。請參照文檔合理比對。
如果服務端 StringToSign 與用戶端一致，請再檢查使用的 AppKey、AppSecret 是否正確，尤其注意是否額外錯誤添加了空格等不容易發現的字元。
Invalid Url
錯誤原因
請求傳入的 HTTP Method 或者 Path 不正確，或者請求指定的環境（X-Ca-Stage）不正確。
如指定調用 TEST 環境的 API，但 API 並未被發布到測試。
注意：
請求時不指定環境，預設為訪問 RELEASE 環境。
對 API 定義有修改，需要重新發布才會生效。許多出現這個錯誤的都是因為修改了 Path 沒發布不生效，用新 Path 請求報錯。
解決辦法
分別檢查上述三個因素：HTTP Method、Path、環境。
API 說明中要求用 POST 則不能用 GET 請求。Method 要一致。
Path 要與當前啟動並執行一致。開放 API 的使用者經常修改之後不發布，導致調用失敗。
指定環境要合理。在請求的 Header 裡有個參數 X-Ca-Stage，取值 TEST/PRE/RELEASE，分別指向測試和線上環境，不傳入該參數則預設是線上。
Unauthorized
錯誤原因
請求 API 時，使用的 AppKey 所屬的 APP 未獲得授權。無權調用 API。
解決方案
授權生效的決定因素有：APP、API、環境、已授權。
如果是開放 API 的使用者自己測試，則需要在 API Gateway控制台，真實建立 APP，然後根據 AppId 在 API 列表頁操作授權。即開放 API 的使用者自測時，其實是自己需要給自己建立的 APP 授權。
如果是購買了 API 的使用者，則在 APP 詳情頁可以查看該 APP 已經被授權的 API，若沒有要調用的 API，則自行操作授權。
如果是使用了夥伴的 API，沒有購買行為的。則聯絡夥伴。您需要提供 AppId，然後由 API 提供者操作授權。
授權關係是有環境屬性的，即 APP、API都是同一個的情況下，授權的環境和請求的環境也要相同。授權了某 API 在 A 環境的許可權，但是也不能調用該 API 在 B 環境中的服務。
最重要的一點是，確認清楚是否用錯了 APP，是否調用錯了 API。由於 API 和 APP 較多，很多使用者因為搞混了而沒能調用成功。比如授權了 APP A，但是調用時候用的是 APP B，請仔細排查。