> For the complete documentation index, see [llms.txt](https://docs.fulfillmenttools.com/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fulfillmenttools.com/documentation/getting-started/facilities.md). # Facilities Facilities represent various locations that form part of the fulfillment network. These locations fulfill distinct roles in ensuring the smooth movement of goods, both inbound and outbound. Managed facilities are fulfillment locations operated and controlled within the network. The defining characteristic of these facilities is that the complete operational fulfillment process — including picking, packing, shipping, and related tasks — is managed internally or by a partner. Suppliers are external entities within the supply chain that provide products to the network. These can include manufacturers, publishers, wholesalers, and distributors, among others. For fulfillmenttools, everything is attached to a facility. Without one, a consumer[^1] could never receive their order. {% hint style="success" %} At least one facility must be created within fulfillmenttools to work. {% endhint %} ## Facility types There are two primary types of facilities: [managed facilities](#managed-facilities) and [supplier facilities](#supplier-facilities). The differentiation between managed and supplier facilities is fundamental for the efficient configuration of any fulfillment network, ensuring that each facility type is leveraged appropriately within the broader order management processes. | Attribute | Managed facilities | Supplier facilities | | ----------------------------- | ------------------------------------- | ------------------------------------------- | | Fulfillment operations | Managed within the network | Managed externally by supplier | | Inventory role | Storage, order fulfillment, transfers | Source of inventory | | Carrier and logistics control | Full visibility and control | Limited or no control | | End customer interaction | Direct fulfillment or pickup possible | Typically not interacting with end customer | | Example entities | Distribution centers, retail stores | Manufacturers, publishers, wholesalers | In the facilities endpoints, these are the `type` of either `MANAGED_FACILITY` or `SUPPLIER`. Depending on which `type` you're using, will determine which fields are required to input. ### Managed facilities Managed facilities represent stores, warehouses, or other locations where orders can be fulfilled. They are fulfillment locations that are directly operated and controlled within the network. The defining characteristic of these facilities is that the complete operational fulfillment process, including picking, packing, shipping, and related tasks, is managed internally or by a partner. Managed facilities represent stores, warehouses, or other locations where orders can be fulfilled. The configuration made for a facility can have an influence on the routing decision as well as on the data displayed in the apps and clients **Key attributes of managed facilities:** * **Physical location and capabilities**: Comprehensive information regarding each facility’s address, working hours, fulfillment capacity, and handling capabilities is maintained within the system. * [**Carrier integrations**](/documentation/by-pillar/store-operations/carrier-management.md): Managed facilities are integrated with specific shipping carriers. The system tracks available carriers as well as their respective pickup times and schedules. * **Fulfillment focus**: Typically, managed facilities handle **direct-to-consumer** deliveries. Orders are picked, packed, and shipped directly to the end customer. In certain cases, customers may also have the option to collect their orders directly from these facilities. * [**Interfacility transfers**:](/documentation/by-pillar/store-operations/interfacility-transfer.md) In addition to serving customers, managed facilities support **i**nterfacility transfers, enabling the efficient movement of stock between different managed locations. A facility has both an external and an internal name. The external name is, for example, used as the sender address on a shipping label and should feature the company name itself. The internal name can be used to differentiate between different facilities. #### **Status** A facility can have one of three statuses with different implications for views and routing: * Online * The facility is considered for order routing * The facility is accessible in Backoffice * Suspended * The facility is not considered for order routing * The facility is accessible in Backoffice * Offline * The facility is not considered for order routing * The facility is not accessible in Backoffice If a facility is no longer used for order fulfillment, it's recommended to set its status to **Suspended**. As a consequence, no new orders are assigned to this facility. After all operational processes have been completed (and no more returns are expected for this facility), the facility can be set to **Offline**. This should be done only if there is no longer any operational need to access the facility. #### **Location type** A managed facility can have a location type of `store`, `warehouse`, or `external`. These can then be used to define routing rules. #### **Service type** A managed facility can be of service type `shipping`, `pickup`, or both. The service type has an impact on the routing decision and on the views and settings in the [Store Operations app](/documentation/apps/store-operations-app.md).
Service typeStore Operations appRouting decision impact
Click-and-collect (pickup)
  • Click-and-collect handover section is shown
Facilities aren't considered in routing decisions, as the decision of which facility the consumer wants to pick up her click-and-collect order from has already been made in the webshop.
Ship-from-Store (shipping)
  • Label section is shown
  • Ship-from-store handover section is shown
  • Switch is shown offering to order a label or pick another task when reaching end of picking
Only facilities of type shipping are considered when routing a ship-from-store order.
#### Fulfillment day and time Fulfillment times are the days and time on which fulfillment is performed in the facility. They can but do not have to be equal to the opening times of a facility. Fulfillment times can be configured for each day individually. Fulfillment times can also be configured within the [network overview settings](/documentation/backoffice/network-view/settings.md) for multiple facilities. Fulfillment times are considered within fulfillmenttools, for example, when a [target time](/documentation/by-pillar/store-operations/picking/pick-job-target-time.md) is generated or when a [time-triggered reroute](/documentation/by-pillar/advanced-order-routing/reroute.md#rerouting-rerouteincaseofinactivity-time-triggeredreroute) takes place. {% hint style="info" %} In case fulfillment times are not configured, there is a fallback on tenant level in place. By default, fulfillment times are set to: Monday-Saturday, from 09:00 to 17:00. {% endhint %} #### Fulfillment capacity The fulfillment capacity can be defined for each time slot within the facility settings. It reflects the number of orders, respectively pick jobs, that can be fulfilled in the time slot. When an order is routed to a facility with capacity information, the capacity value is reduced by the order for the [next free capacity slot](/documentation/by-pillar/advanced-order-routing/ratings.md#ratings-nextfreecapacity-2). To ensure that fulfillment capacities are considered within the routing, the capacity [fence](/documentation/by-pillar/advanced-order-routing/fences.md) or [rating](/documentation/by-pillar/advanced-order-routing/ratings.md) need to be activated. [See the Pick job target time article](/documentation/by-pillar/store-operations/picking/pick-job-target-time.md) for more information on how the target time of an order is calculated considering capacities. #### **Fulfillment closing times** Fulfillment closing times are certain days where no fulfillment at all takes place such as Sundays or holidays. Fulfillment closing days can also be configured within the [network overview settings](/documentation/backoffice/network-view/settings.md#fulfillment-times-for-multiple-facilities) for multiple facilities. {% hint style="warning" %} If a bulk update on fulfillment times and closing days is saved, already submitted times are overwritten. {% endhint %} #### Average fulfillment duration (fulfillment buffer) Average fulfillment duration is a lead time or buffer time which represents the time it takes for an order to be ready for handover to the shipping provider or to the customer. This corresponds to the time from the creation of the pick job to the completion of the handover. It is used to check whether a successful completion of the order can be ensured in a facility. {% hint style="info" %} This buffer time can be defined on facility level via [facility REST API](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#patch-/api/facilities/-facilityId-) and in [Backoffice](/documentation/backoffice/facility-view/facility.md). Furthermore, an admin can define a tenant-wide default fallback via the [fulfillment process buffer REST API](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#put-/api/configurations/fulfillmentprocessbuffer), which is initially set to 240 minutes. {% endhint %} #### Carrier Users can assign different carriers to a facility. With this information a [fence](/documentation/by-pillar/advanced-order-routing/fences.md) can be implemented where orders which need to be shipped by a chosen carrier are routed to a facility where this carrier is active. Carriers that are enabled on tenant level must also be enabled for the facilities in which the carrier is available. #### Short pick A short pick describes the case when an order could not be completely picked. This can happen when some ordered items were too low in stock or out of stock. By enabling the config, stock for an item in a facility is set to zero, if nothing or not enough could be picked for that item. {% hint style="warning" %} We strongly advise users to simultaneously activate the `confirmationOnShortPick` in the [picking configuration](/documentation/by-pillar/store-operations/picking.md#picking-configuration). Otherwise systems cannot differentiate between cases where the user tried to pick an item and failed due to no available stock or cases where the pick job was rerouted before the user even tried to pick all ordered items. {% endhint %} {% hint style="info" %} This setting can be defined in the facility section of the [Backoffice](/documentation/backoffice/network-view/settings.md) or via [facility stock configuration REST API](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#patch-/api/facilities/-facilityId-/configurations/stock). {% endhint %} #### Storage principles Storage principles for stock properties (such as expiry date) can be defined for each facility. The unmixed storage principle means that the same item with different properties (for example, expiry date) must not be stored on the same storage location. Enabling unmixed storage has the following effects: * If a user tries to stow the same items with different properties on the same storage location, a user warning is shown. * Storage location recommendations are only locations where the unmixed storage principle is met. The unmixed storage configuration should be deactivated if stock properties are not relevant while stowing or relocating items. {% hint style="info" %} This setting can be defined in the facility section of [Backoffice](/documentation/backoffice/network-view/settings.md) or via [facility inventory configuration API](https://fulfillmenttools.github.io/fulfillmenttools-api-reference-ui/#patch-/api/facilities/-facilityId-/configurations/inventory). {% endhint %} ### Supplier facilities Suppliers are external entities within the supply chain that provide products to the network. These might include manufacturers, publishers, wholesalers, and distributors, among others. In contrast to managed facilities, the operational responsibility at supplier locations lies entirely outside the network's control. A supplier may operate multiple physical locations, but these individual sites are typically not known to the fulfillment network. Consequently, the supplier facility information, such as addresses, working hours, capacity limits, or specific shipping carrier integrations aren't maintained for supplier facilities. **Key attributes of suppliers:** * **External fulfillment operations**: Unlike managed facilities, the operational fulfillment processes at supplier locations are outside the direct control of the network. Tasks such as picking, packing, and shipping are managed by the suppliers themselves, following their own processes and schedules. * **Supply chain role**: Suppliers primarily act as the upstream source of inventory, supplying goods to be stocked within managed facilities or shipped directly depending on the fulfillment strategy. #### Implication on routing decisions This lack of visibility has important implications for certain standard [routing rules](/documentation/by-pillar/advanced-order-routing/routing-strategy.md). Since key data points about supplier facilities are unavailable, some rules can only consider the supplier part of the supply chain to a limited extent when dealing with supplier facilities. For example: * The **geo distance rating** does not factor in transport routes originating from suppliers, as their exact locations might not be known. * The **country fence** rule does not take into account the geographical location of supplier facilities. These constraints should be considered when configuring routing strategies, especially when suppliers play a significant role in the overall fulfillment flow. #### Supplier facility data Supplier facility data is limited to a few key attributes due to the reasons mentioned above. These attributes are interpreted similarly to those of managed facilities:
FieldTypeInformationRequired
namestringA descriptive name of the supplier facility to identify it.Yes
statusenumThe status of the supplier facility. See the Facility status section for enum options and their definitions.Yes
tenantFacilityIdstringAn identifier that often serves as a foreign key corresponding to an ID in an external system. See the URN pattern parameters section for more details.No
addressobjectThe address of the supplier facility.No
customAttributesobjectStore any relevant data to the entity you want (within reason) if our current properties don't fit your needs. See the custom attributes article for more details.No
tagsarrayMap individual processes and customize entities. See the tags article for more details.No
{% hint style="info" %} Supplier facilities can also have [listings](/documentation/by-pillar/global-inventory-hub/listing.md) assigned to them. But [facility carrier connections](/documentation/by-pillar/store-operations/carrier-management.md) and [facility custom service connections](/documentation/by-pillar/store-operations/services/custom-services.md) can't be applied for supplier facilities. {% endhint %} ## Create a managed facility {% hint style="info" %} You can also create [facilities in Backoffice](/documentation/backoffice/network-view/facilities.md). {% endhint %} {% stepper %} {% step %} **Make the `POST` request to create a facility** {% tabs %} {% tab title="Endpoint" %} ```http POST https://ocff-{PROJECT_ID}.fulfillmenttools.com/api/facilities ``` {% endtab %} {% tab title="Request" %} ```json { "name": "Nerd Herd Clothing", "type": "MANAGED_FACILITY", "address": { "companyName": "Nerd Herd Clothing Ltd", "country": "US", "postalCode": "42420", "city": "Los Angeles", "street": "Bison Drive", "houseNumber": "42" }, "services": [ { "type": "SHIP_FROM_STORE" } ], "status": "ONLINE", "locationType": "STORE" } ``` {% hint style="info" %} The fields `services` and `locationType` are not required, but it's highly recommended to include at least the `services` section so the store can receive orders. {% endhint %} {% endtab %} {% tab title="Response" %} If the request is successful, you'll receive a `201 CREATED` response with a body like this: ```json { "name": "Nerd Herd Clothing", "type": "MANAGED_FACILITY", "address": { "companyName": "Nerd Herd Clothing Ltd", "country": "US", "postalCode": "42420", "city": "Los Angeles", "street": "Bison Drive", "houseNumber": "42" }, "services": [ { "type": "SHIP_FROM_STORE" } ], "status": "ONLINE", "locationType": "STORE", "fulfillmentProcessBuffer": 240, "capacityEnabled": false, "created": "2023-08-22T14:39:27.014Z", "lastModified": "2023-08-22T14:39:27.014Z", "version": 1, "id": "{YOUR_UNIQUE_FACILITY_ID}" } ``` {% endtab %} {% endtabs %} {% endstep %} {% step %} **Add precise latitude and longitude** Each facility needs valid geo coordinates (latitude and longitude) for use in the routing engine. If coordinates are missing in the `address` object, the system will attempt to resolve them based on the provided address (city center). To provide precise coordinates, include `resolvedCoordinates` inside the `address` object, for example: {% code title="address-with-coordinates.json" %} ```json { // Facility object ... "address": { ... "resolvedCoordinates": { "lat": 50.937531, "lon": 6.960279 } } } ``` {% endcode %} City center approach geo data is based on [opendatasoft](https://public.opendatasoft.com/explore/dataset/geonames-postal-code/information/) under the [CC BY 4.0 license](https://creativecommons.org/licenses/by/4.0/). {% endstep %} {% endstepper %} Once created, you can edit the facility details, including updating the status, using the below endpoint: ```http PUT https://ocff-{PROJECT_ID}.fulfillmenttools.com/api/facilities ``` {% hint style="info" %} These details can also be edited in Backoffice in both the [Network](/documentation/backoffice/network-view/facilities.md) and [Facility](/documentation/backoffice/facility-view/facility.md) views if you have the necessary permissions. {% endhint %} ## Create a supplier facility {% hint style="info" %} You can also create [facilities in Backoffice](/documentation/backoffice/network-view/facilities.md). {% endhint %} To create a supplier facility, make the `POST` request below: {% tabs %} {% tab title="Endpoint" %} ```http POST https://ocff-{PROJECT_ID}.fulfillmenttools.com/api/facilities ``` {% endtab %} {% tab title="Request" %} ```json { "name": "Nerd Herd Distribution", "type": "SUPPLIER", "status": "ONLINE" } ``` {% endtab %} {% tab title="Response" %} ```json { "type": "SUPPLIER", "name": "Nerd Herd Distribution", "status": "ONLINE", "version": 1, "lastModified": "2026-07-10T12:26:46.790Z", "id": "{YOUR_UNIQUE_FACILITY_ID}", "created": "2026-07-10T12:26:46.790Z" } ``` {% endtab %} {% endtabs %} [^1]: The end user is making the purchase, whether online or offline. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.fulfillmenttools.com/documentation/getting-started/facilities.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.