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
  • Lifecycle Overview
  • Alpha
  • Beta
  • GA (General Availability)
  • Deprecated
  • Breaking Changes
  • Enum handling
Edit on GitHub
  1. API
  2. Core concepts

API Versioning & lifecycle

The fulfillmenttools API is considered versionless. That means that our API evolves in a backward-compatible way. The following changes, are considered to be backward-compatible:

  • Adding new API resources.

  • Adding new optional request parameters to existing API methods.

  • Adding new properties to existing API responses.

  • Changing the order of properties in existing API responses.

  • Adding values to enums (see Enum Handling)

All endpoints, fields, and types in our APIs have a lifecycle ranging from Alpha to Beta to GA (generally available). Additionally, we may deprecate certain functionality in our API.

We mark endpoints, types, fields, or features by their release life cycle. These are included as flags (see details in the corresponding sections). Consider the following example:

'/api/facilities/{facilityId}':
  get:
    operationId: getFacility
    summary: Get a facility with the given ID
    x-fft-api-lifecycle: ga
    responses:
      '200':
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Facility'

components:
  schemas: 
    Facility:
      properties:
        id:
          type: string
          x-fft-api-lifecycle: ga
        description:
          type: string
          x-fft-api-lifecycle: alpha

In this case, the facility endpoint and entity are both generally available. However, the description field is still under construction and may change. When working with the facility endpoint, ensure that the information provided in the description field is not integrated into any mission-critical components that may be sensitive to changes.

In GraphQL, lifecycle information is implemented via schema directives. Schema directives except for @deprecated are not fetched during introspection. We recommend manually fetching the latest schema from our API hub.

type Query {
  facility(id: String!): Facility @FFTMetadata(lifecycle = GA)
  listings: ListingConnection @FFTMetadata(lifecycle = GA)
}

type Facility @FFTMetadata(lifecycle = BETA) {
  id: ID! @FFTMetadata(lifecycle = GA)
  name: String! @FFTMetadata(lifecycle = GA)
  description: String! @FFTMetadata(lifecycle = ALPHA)
  
  listings: ListingConnection @semanticNonNull @FFTMetadata(lifecycle = BETA)
}

type ListingsConnection @FFTMetadata(lifecycle = GA) {
  edges: [ListingEdge] @semanticNonNull(levels = [0,1]) @FFTMetadata(lifecycle = GA)
}

The above example shows a typical case for mixed lifecycle flags in our GraphQL schema. Querying a facility and its ID and name can be achieved using GA fields, which are fully covered under our SLAs. The same holds for listings, including filters like the facilityRef of the listing. However, querying all listings in a facility using Facility.listings, a non-GA field is not covered under the SLAs. Additionally, the description field is still under construction and may change. When working with the facility endpoint, ensure that the information provided in the description field is not integrated into any mission-critical components that may be sensitive to changes.

Lifecycle Overview

Lifecycle State
SLAs
Breaking changes
Change Notifications

Alpha

❌

common

no notifications

Beta

❌

rarely

no later than two weeks before breaking changes

GA

️✅

❎

-

Deprecated

️✅ if Endpoint was previously GA

❎ if Endpoint was previously GA

-

Alpha

Please contact us if you want to use endpoints marked with the Alpha tag.

Beta

Please contact us if you want to use endpoints marked with the Beta tag.

GA (General Availability)

Endpoints without any flag are production-ready and stable endpoints. We serve these endpoints within our SLAs.

Deprecated

In some cases, we might deprecate endpoints or attributes. Deprecated endpoints contain hints to new endpoints, replacing their functionality or providing a newer feature version. We monitor deprecated endpoints to ensure we only remove functionality when nobody uses it. Deprecated endpoints are still served within our SLAs if they had previously made it to GA.

Breaking Changes

When an endpoint is under active development (e.g., marked as Alpha or Beta), we might change its semantic and/or syntactic behavior. You will find Alpha or Beta flags on resources, types (or part of types), and other places under development. If you encounter such a flag, it means the following:

  • This endpoint, type, or field might be subject to breaking changes.

  • It might not be available at all times.

  • It could disappear without specific warning.

  • It currently does not fall under our SLA regulations.

Enum handling

Our schemas use plenty of enums, for example, for status use. Please be aware that adding a value to it is considered a nonbreaking change:

OrderStatus:
  type: "string"
  enum:
    - "OPEN"
    - "CANCELLED"
    - "LOCKED"
+   - "CLOSED"
enum OrderStatus {
   OPEN
   CANCELLED
   LOCKED
+  CLOSED 
}

However, the tooling around this use of enumerations varies: A code generator will most likely produce enums that cannot contain values different from the one described. If you are handling enums, the best practice is to map unknown enum values to ones you recognize or that yield an error.

Last updated 4 months ago

Alpha endpoints are currently in development and might not be fully functional. Therefore, (both semantic and syntactical) are common. We change these endpoints without communication. Additionally, alpha endpoints are not contained in our SLAs.

Alpha Flag

Endpoints with the Beta life cycle state are more mature but still under active development. We try to prevent . Nevertheless, breaking changes are possible in rare cases. There already exists functionality at these endpoints, but we don't cover these in our SLAs. Breaking changes are communicated to clients two weeks before the change.

Beta Flag
breaking changes
breaking changes