API Consumer Shape 的核心責任是把「消費者」這個詞拆開。契約決策談到消費者時，指的其實是四種行為完全不同的對象，而混用會讓判準失準：有的會在契約被改壞時發 email 抱怨，有的默默做出錯誤決定且永遠不會回報。這張卡跟 Consumer 是同名異義——那張講的是訊息佇列裡取出工作的角色，這張講的是對外契約的另一端。

概念位置

四種形態的分野是會不會回報與改不改得動兩個軸。

有人格的整合團隊：另一家公司或另一個團隊的工程師，用這個 API 寫了程式。他們會讀 changelog（有些會）、會在壞掉時開票、改得動自己的 client 但需要時間與排程。版本退場的通知對象是這一類，而 Deprecation Lifecycle 的整套工具箱假設的也是他們。

非人格的中介：proxy、快取層、負載平衡器、監控系統、泛型 HTTP client 函式庫。它們依據 transport 層的訊號自動做決定——看到 200 就快取、就重試、就判定後端健康——而它們不讀文件、不會抱怨、做錯決定時沒有任何訊號。錯誤格式與 status 語意的決策，真正的受害者多半是這一類（見 錯誤格式之爭）。

內部呼叫端：同一個 repo 或同一個發布單位裡的服務。它們的特殊性在於可以原子更新——契約與呼叫端在同一次提交裡改完，因此不需要任何機制讓新舊行為並存，版本識別碼在這裡是純成本。把它們當成「數量少的外部消費者」是常見的誤判：外部消費者再少也要一個切換點讓新舊並存，而可原子更新的一組根本不需要那個切換點。

聯絡不到的外部整合方：經第三方 marketplace 轉售的終端客戶、不可更新韌體的裝置、已停止維護但還在跑的整合。它們的存在通常知道、身分則不知道，而任何遷移計畫的完成率都會停在某個數字以下。服務端對這一類實際上等於永久供應舊行為，不論當初承諾的窗口是多久。

可觀察訊號與例子

同一個 API 通常同時有多種形態，而它們的比例決定了契約策略。一個對外的 SaaS API 可能有三家會開票的大整合方、兩百家只在壞掉時才出現的小整合方、每個請求都經過的 CDN 與 WAF、以及自家後台這個內部呼叫端——四種都在。

判斷自己面對哪一種，最快的問法是：這個對象在契約被改壞的隔天會做什麼。開票是第一種，靜默做出錯誤決定是第二種，跟契約在同一次提交裡一起改完、所以根本不會壞是第三種，幾個月後由客服轉述才知道的是第四種。

設計責任

契約決策要標明它服務的是哪一種形態，否則判準會被套到錯的對象上。三個高頻誤用：把內部呼叫端當成「消費者少」而選了 URI 版本（可原子更新的情境根本不需要版本識別碼）、把非人格中介的失明算進「消費者可以看文件」（它們不看）、以及把聯絡不到的那類漏出通知名單（它們不會主動出現，直到退場當天）。

各形態對應的版本策略分流見 版本策略流派之爭 的判定序；怎麼在觀測上把它們分開見 11.12 API 消費者用量觀測；判斷第一種形態能不能協調得動見 Consumer Coordinability。