Kustomer 限制
以下是 Kustomer 的限制或備註:
不支援
Customer Searches實體,因為 Kustomer API 文件尚未為其宣告任何端點。不支援對
Klasses實體進行篩選和增量傳輸。單一請求中的多個適用欄位可支援排序依據。
不過,對於某些組合,已觀察到 SaaS 終端的多個欄位的排序依據功能行為不一致。其無法預測,因為有可能顯示不正確排序結果的 'n' 個組合。例如:
對於
Customers實體,按progressiveStatus desc, name asc排序不會產生正確的排序結果。其只會根據progressiveStatus順序排序。如果發現此類行為,可以使用單一欄位進行排序。Conversations和Messages實體僅支援欄位 'id' 的排序依據作為查詢參數。例如:https://api.kustomerapp.com/v1/conversations?sort=desc (這會以遞減順序按照 'id' 對結果進行排序。)此外,任何其他欄位上的篩選條件或排序會轉換為將 API 端點作為 POST 的 POST 請求內文 https://api.kustomerapp.com/v1/customers/search 若要允許在
Conversations和Messages中依 'id' 排序,應該只存在依 id 排序,或在任何其他適用欄位存在任何其他篩選條件和/或排序依據。無論是已篩選還是未篩選的請求,Kustomer 允許擷取最多 10K 筆記錄。由於此限制,持有超過 10K 筆記錄的任何實體都會遺失資料。可以執行兩種可能的解決方法,以部分緩解此問題:
套用篩選條件來擷取一組特定記錄。
如果已套用的篩選條件具有超過 10K 筆記錄,請在新的後續請求中套用連續篩選條件值,或在篩選條件中套用範圍。例如:
第一個請求的 filterExpression:
modifiedAt >= 2022-03-15T05:26:23.000Z and modifiedAt < 2023-03-15T05:26:23.000Z假設這會耗盡 10K 筆記錄限制。
可以使用 filterExpression 觸發另一個請求:
modifiedAt >= 2023-03-15T05:26:23.000Z
作為 SaaS 行為,Kustomer 中的
CONTAINS運算子僅支援對完整字詞進行比對,而不是對字詞進行部分比對。例如:"body CONTAINS 'test record'" 將比對 'body' 欄位中具有 'test' 的記錄。不過,"body CONTAINS 'test'" 不會比對 'body' 欄位中具有 'testAnotherRecord' 的記錄。