Search

Introduction

More Search-API information can be found in the API documentation for the respective search endpoint (for example for inbound process: REST API documentation - Inbound Process)

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.

Mandatory query fields

Some entities, especially entities that represent historical data, have mandatory fields in the query, i.e. search fields that must be specified in any case. This serves to limit the amount of data.

For example, for operational entities (e.g., orders) usually only entities that were created recently are of interest. This means, not all entities that have ever been created need to be searched. However, there are no restrictions on the filter content. For example, users can fill a mandatory search criterion such as created with { gt: '1970-01-01T00:00:00Z'} , if interested in the data.

Search function limitations

The search functionality has restrictions due to database constraints and performance considerations. These limitations ensure stability and efficiency when handling queries.

1. 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.

2. 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.

3. 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 API calls

Searching for exact equal matches

Example: Search for stocks in facility with facilityRef d083f631-9f4c-463b-85d4-9414fb19239f.

POST https://{YOUR-TENANT-NAME}.fulfillmenttools.com/api/stocks/search

{
    "query": {
        "facilityRef": {
            "eq": "d083f631-9f4c-463b-85d4-9414fb19239f"
        }
    }
}

Searching with gt, gte, lt and lte operators

Example: Search for storage locations created before the 2nd October 2024.

POST https://{YOUR-TENANT-NAME}.fulfillmenttools.com/api/storagelocations/search

{
    "query": {
        "created": {
            "lt": "2024-10-02T14:43:21.257Z"
        }
    }
}

Sorting search results

POST https://{YOUR-TENANT-NAME}.fulfillmenttools.com/api/{ENTITY-NAME}/search

{
    "sort": [
        {
            "<attribute_to_sort_by>": "ASC"
        }
    ],
    "query": {
      ...
    }
}

Adding a search result total count

The total count can significantly slow down the response time of the request.

POST https://{YOUR-TENANT-NAME}.fulfillmenttools.com/api/{ENTITY-NAME}/search

{
    "options": {
        "withTotal": true
    },
    "query": {
      ...
    }
}

Searching for several fields in conjunction with and/or

Example: 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.

POST https://{YOUR-TENANT-NAME}.fulfillmenttools.com/api/stocks/search

{
    "query": {
        "and": [
            {
                "facilityRef": {
                    "eq": "d083f631-9f4c-463b-85d4-9414fb19239f"
                }
            }, {
                "locationRef": {
                    "in": [
                        "6779689d-4852-4fcf-b13b-78f5ce4954d8",
                        "3b8be595-6a00-40cf-be09-12195e44eb99"
                    ]
                }
            }
        ]
    }
}

Searching for nested fields

Example: Search for inboundProcesses with a purchaseOrder with ID 678ujnuzb67vg8h8oji.

POST https://{YOUR-TENANT-NAME}.fulfillmenttools.com/api/inboundprocesses/search

{
    "query": {
        "purchaseOrder": {
            "id": {
                "eq": "678ujnuzb67vg8h8oji"
            }
        }
    }
}

Searching for custom attributes

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 locations with user-defined custom attributes that should be searchable and execute the search.

1. Create a new entity with user-defined custom attributes that should be searchable (searchTerms)

POST https://{YOUR-TENANT-NAME}.fulfillmenttools.com/api/{facilityId}/storagelocations

...
"customAttributes": {
  "searchTerms": {       
    "TYPE": "FROZEN"     
  }
}
... 

1. Construct a search query on custom attributes

POST https://{YOUR-TENANT-NAME}.fulfillmenttools.com/api/storagelocations/search

{
  "query": {
    "customAttributes": {
      "searchTerms": {
        "TYPE": {
          "eq": "FROZEN"
        }
      }
    }
  }
}