Search
Last updated
Last updated
Searchable fulfillmenttools entities have their own search endpoint, located at: POST /api/{ENTITY-NAME}/search. Every fulfillmenttools entity defines which fields are queryable in its search endpoint.
Strings and numbers can be searched with the operators
eq and notEq (search value needs to be a string) or
in and notIn (search value needs to be an array of strings)
Arrays of strings can be searched with the contains operator
Numbers and date values can be searched with the operators gt (>), gte (>=), lt (<) and lte (<=)
customAttributes are fully searchable. However, to optimize performance, we recommend storing search-relevant keys in a dedicated property (e.g., searchTerms) and minimizing nesting depth.
Some entities (particularly those representing historical data) include default filters in queries. These default search fields are designed to limit the amount of data returned, improving performance and relevance.
For example, operational entities such as orders typically return only recently created records by default, as older data is often not relevant for current operations.
These default values can be overwritten if needed. However, we recommend caution when expanding filters, especially when querying large datasets, to avoid performance issues.
The search functionality has restrictions due to database constraints and performance considerations. These limitations ensure stability and efficiency when handling queries.
No dots (.) in custom search field names: Field names containing dots (.) can cause conflicts with internal database structures and indexing mechanisms. To prevent issues, dots are not allowed in custom search field names.
No custom search fields starting with a dollar sign ($): Field names beginning with a dollar sign ($) conflict with database operators, which use this syntax for system commands. To avoid ambiguity, such field names are not permitted.
Cross-entity search via referenced filter is limited to top-level queries: Cross-entity searches using the referenced filter can only be applied at the top level. Nesting them within AND or OR conditions is not supported due to query optimization constraints.
Example: Search for stocks in a facility with facilityRef d083f631-9f4c-463b-85d4-9414fb19239f.
gt, gte, lt and lte operatorsExample: Search for storage locations created before the 2nd October 2024.
The total count can significantly slow down the response time of the request.
and/orExample: Search for stocks in facility with facilityRef d083f631-9f4c-463b-85d4-9414fb19239f and that are placed on locations 6779689d-4852-4fcf-b13b-78f5ce4954d8 and 3b8be595-6a00-40cf-be09-12195e44eb99.
Example: Search for inboundProcesses with a purchaseOrder with ID 678ujnuzb67vg8h8oji.
Fields in customAttributes can be made searchable by defining key-value pairs within the searchTerms property. All defined key-value pairs are then queryable in the search endpoints. The customAttributes can contain strings and numbers. For strings, the in and notIn operators are allowed. For numbers, the operatorslt, lte, gt, gte are additionally available.
It is important to use numbers when searching for a number attribute and strings when searching for a string attribute. Otherwise, the search will not give back the desired results. For example, if the search value is the number 5, a query search for eq: "5" would not be successful.
Example: Create a new storage location with user-defined custom attributes that should be searchable and execute the search.
Create a new entity with user-defined custom attributes that should be searchable (searchTerms)
Construct a search query on custom attributes