fulfillmenttools
API documentationIncident ManagementFeedback
Developer Docs
Developer Docs
  • Developer docs
  • Getting Started
    • Quickstart
    • Integration tutorial
      • Adding facilities
      • Adding listings to facilities
      • Configuring stocks
      • Carrier configuration
      • Placing orders
      • Checkout options
      • Distributed Order Management System (Routing)
      • Local fulfillment configuration
    • Free trial
  • Technical Basics
    • Access to fulfillmenttools
    • Feature status
    • Available regions
    • Backup policies
  • Connecting to fulfillmenttools
    • Client SDKs
    • commercetools connect
    • OpenID connect
      • Configure Microsoft Entra ID / Azure Active Directory
      • Configure Keycloak
  • API
    • Core concepts
      • Authentication & authorization
      • API Versioning & lifecycle
      • Assign user to jobs
      • Localization
      • Resource timestamps
      • Custom attributes
      • Article attributes
      • Recordable attributes
      • Data update guarantees
      • Rate limits & scaling
      • Retries
      • Performance on test vs. production systems
      • Load testing
    • API calls
      • Postman
      • cURL
      • GraphQL Explorer
    • GraphQL API
    • RESTful API
      • Pagination interface
      • RapiDoc
      • OpenAPI 3.0 Spec
    • Eventing
      • Structure of an event
      • Available events
        • Event flows
      • Eventing example
      • Event export
  • Integration Guides
    • Basics
      • Article categories
      • Audits
      • Facilities
      • Facility groups
      • GDPR configuration
      • Listings
      • Remote configuration
      • Receipts
      • Search
      • Subscribe to events
      • Sticker
      • Stocks
      • Storage locations
      • Tags
      • Users
    • Channel inventory
    • Inbound process
    • Outbound stocks
    • Purchase order
    • Receipt
    • Routing strategy (context-based multi-config DOMS)
    • Show sticker to clients
    • Stow jobs
  • More Integration Guides
    • Carrier management
      • Introduction to carrier configuration
      • Required data when operating carriers
      • Adding & connecting carriers to facilities
      • Custom carrier
    • Configurations for order fulfillment
      • Picking configuration
      • Packing configuration
      • Handover configuration
      • Printing and document configuration
      • Packing container types
      • Parcel tag configuration
      • Headless order fulfillment
      • Short-pick reasons
      • External documents in order fulfillment
      • Service jobs
      • Load units
      • Running sequence
    • DOMS - distributed order management system (routing)
    • External actions
    • Interfacility transfer
    • Notifications
    • Orders
      • Place your first order
      • Ship-from-store orders
      • Click-and-collect orders
      • Locked orders
      • Order with custom services
      • Bundled items in an order
      • Order process status
    • Availability & promising
    • Returns
Powered by GitBook
On this page
  • Configuring handover refuse reasons
  • Localization for reasons
Edit on GitHub
  1. More Integration Guides
  2. Configurations for order fulfillment

Handover configuration

Configuring handover refuse reasons

Reasons why customers have rejected the order on handover can be stored in the handover configuration. They are called "refused reasons". The list of available reasons can be set up here in different languages and can be retrieved with a GET call to the available endpoint.

Request for setting handover configuration
curl -sSL -X PUT 'https://your.api.fulfillmenttools.com/api/configurations/handover' \
--header 'Authorization: Bearer <TOKEN>' \
--header 'Content-Type: application/json' \
--data-raw '{
    "availableRefusedReasons": [
        {
            active: true,
            refusedReasonLocalized: {
                "en_US": "wrong color",
                "de_DE": "falsche Farbe"
            }
        },
        {
            active: false,
            refusedReasonLocalized: {
                "en_US": "wrong size",
                "de_DE": "falsche Größe"
            }
        },
    ],
    "version": 42,
}'

When handing over the products to the customer or delivery service you might want to offer the possibility of refusing to accept the products to the receiving party. At the same time you might want to mark the refused products with a reason why the products were not accepted.

Localization for reasons

The response has a refusedReason field that contains one of the locales provided by refusedReasonLocalized object. Which exact translation was chosen depends on the locale set in the authorization token when sending the request to the GET endpoint.

If no locale was provided by the client or the locale is not available in the refusedReasonLocalized field, the answer will default to the tenant locale. If the tenant locale is also not available in the refusedReasonLocalized object, then the first key value pair will be selected.

Last updated 5 months ago