為何請求成功仍可能漏資料
匯入工作可能顯示「成功」，原因只是第一個網絡請求得到正常回應，但業務報表其實只收到第一頁紀錄。不少 API 會把清單分頁。以 Microsoft Graph 為例，若還有下一頁，回應會附上 @odata.nextLink；官方文件要求客戶端逐頁跟隨，直到不再有下一頁連結，才算讀完。指定每頁筆數，也不代表整份清單會在一次回應內出現。負責人應把成功定義為整輪匯入完整並經核對，而非一個綠色網絡狀態。存貨、客戶或發票資料進入儀表板或另一套系統前，這個分別尤其重要。
首先界定這輪工作要取得哪些紀錄：整個清單、某段日期，還是上次完成後的變更；亦要指出哪套系統是權威來源。逐頁讀取期間，來源紀錄可能被修改，清單未必是一張固定快照。匯入程式應說明來源 API 真正提供哪種一致性保證；若文件沒有保證，就要安排核對和稍後補讀。把業務工作單位寫清楚，例如「取得上次完整檢查點後更新的所有訂單」，比「請求完成」有用。部分結果不可悄悄覆蓋上一份完整資料。
跟隨伺服器提供的游標
應把供應商回傳的下一頁網址或游標視為不透明值。除非該 API 明確容許，不要自行在第一頁網址加數字來猜第二頁。Microsoft Graph 文件指出，$top、$skip 及跳頁代碼是否可用，會因端點而異；其中 /users 的例子支援 $top，卻不支援 $skip。保存啟動該輪工作的查詢，跟隨回傳連結，並在每頁通過檢查後處理。按文件定義，沒有後續連結的一頁才是最後一頁。若伺服器明示還有下一頁，即使本頁筆數較少，也不能當作已完成。
可用的匯入器應記錄每輪編號、來源端點、起始界線、續頁狀態、已取得頁數、接納的紀錄識別碼和最後完成的檢查點。若續頁網址含權杖或敏感參數，應按操作機密保護，不要貼進公開錯誤紀錄。載入每一頁前，要核對回應結構和必需識別碼。把原始讀取與發布完成資料分開，員工便可調查某一頁的問題，而不會把新舊混合資料當成乾淨報表，也較易分辨來源原本缺資料，還是自家匯入器漏了資料。
處理限流及中斷的頁面
收到 429 回應不是得到空白頁，也不能把檢查點推前。Microsoft Graph 指引要求遇到限流時按 Retry-After 指定時間等待再試；若沒有該標頭，建議採用指數退避。立即反覆發送請求可能延長限流。其他供應商的狀態碼和限制或有不同，應依其文件實作，不要照抄 Graph 規則。亦要分清暫時服務故障與永久的權限或查詢錯誤。警報應指出哪一輪、哪一頁失敗、已重試多少次，以及用戶是否仍可查看上一份完整資料。
重試時應處理同一個邏輯頁面，完成前不要提交進度。Microsoft Graph 特別提醒：若把重試過程產生的代碼用於之後的頁面，可能觸發 DirectoryPageTokenNotFoundException；使用該服務時須遵循其代碼指引。一般整合則應設計可重複執行的頁面載入：以穩定的來源識別碼辨認紀錄，採用更新插入或暫存表，避免重試產生重複業務資料。收到回應不等於已安全儲存。只有在檢查和寫入均持久完成後，才連同準確續頁狀態及該輪背景資料提交檢查點。
用一輪部分匯入作演練
假設批發商夜間匯入供應商產品。第一頁有熟悉產品，第二頁有近期新增貨品，第三頁暫時失敗。若工作把前兩頁發布為完整目錄，員工可能誤以為第三頁的貨品已被刪除。正確狀態應是「未完成」。先保留上次核實的目錄，按供應商規則重試失敗頁，直到續頁鏈結結束並通過檢查，才發布新資料。這是假設情境，不是已觀察到的事故，也不是對某供應商的指控；目的是具體說明靜悄悄的部分匯入會如何影響業務判斷。
驗收時應注入多種情況：多頁結果、文件容許的空白末頁、附 Retry-After 的 429、收到資料後發生網絡逾時，以及格式錯誤紀錄。檢查任何情況都不會太早標示完成。重讀同一頁，確認目的地每個來源識別碼仍只有一筆。中斷程序，再用已保存狀態恢復。之後抽查已知來源樣本，並比較筆數或供應商支援的其他核對證據。筆數相同不能證明每項都正確，但突然下降是一個警號。要事先界定哪些差異必須阻止發布，哪些交由人手覆核。
選擇可持續的更新方式
首次完整匯入與日常更新是兩種工作。每晚重讀整個清單雖然簡單，大清單卻可能耗時並觸及限制。Microsoft Graph 的限流指引提醒，定期掃描整個集合和持續輪詢較容易受到限制。若特定來源支援差異或變更查詢，可評估改用，但要弄清刪除、代碼過期及補讀如何表示。不要只因名稱聽起來有效率便轉用增量方法；須測試它是否涵蓋目的地真正需要的業務變更。定期全面核對可能仍有必要，以發現錯過或誤解的事件。
業務端需要看得懂的運作狀態：上次完整匯入時間、來源涵蓋範圍、讀取頁數、接納和拒絕的紀錄、等待重試的工作，以及已發布資料的時效。仍在暫存中的一輪不能顯示「已更新」。警報門檻應按企業能承受資料過時多久來訂，不要套用憑空想像的通用時限。下一步可追查現有一輪匯入，從首個請求一直看到發布，找出哪一步證明所有頁面均已到達。若沒有證明，應先加完成和核對檢查，再用該資料作重要決策。Astera 可按來源 API 的真實能力協助設計整合約定及監察方式。
保留權限及資料責任界線
要取得完整資料，不代表匯入器可以要求無限權限。只授予其業務用途需要的權限及欄位，並記下誰能更換憑證和查看紀錄。查詢條件一旦改變，應重新啟動或明確標示新版本，不要把舊續頁連結套進新範圍。供應商新增的欄位可能在舊紀錄不存在；回應突然少了一個欄位，也可能是權限變更。這類結構變化應觸發覆核。否則即使頁面鏈結技術上讀完，若必要資訊被悄悄丟掉，業務資料仍然不完整。
每份匯入資料都應指定一位負責定義「完整」的業務人員。工程師可證明程式跟隨了所有續頁連結，但倉庫主管可能才會發現查詢漏掉停賣貨品、款式或退貨。上線前先約定涵蓋這些情況的樣本紀錄。每筆已發布資料都應能追溯來源識別碼及匯入輪次，以便調查有爭議的數字。若 API 沒有可靠總數或快照功能，要坦白說明限制，並以來源介面作針對性抽查。這比一般的成功訊息有力，也承認不能自動證明的部分。
採用匯入資料前
- 按文件跟隨每個續頁值，直到來源確認清單完結。
- 把限流與逾時視為未完成，恢復時避免重複紀錄。
- 完成核對後才發布已驗證的完整資料。
