Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

API-based offerings

WAL-762 - Getting issue details... STATUS

Request-based offerings

Waldur supports configuration of offerings, which lead to creation of a new service request in Helpdesk for manual processing. Typically, this is needed for setting up and exposing over API offerings that cannot be automated or require offline negotiations.

Configuration of offerings is done in Waldur MasterMind configuration file, under OFFERINGS section of WALDUR_SUPPORT configuration.

High-level idea

Provisioning an offering of the request-based type, will lead to creation of offering request model and a ticket in the Helpdesk backend with a summary: 'Request for '{Offering_label}'. 'Offering_label' is going to be taken from configuration of the offering, in particular from 'offering_type→label' section. If label is not present a name of the section will be used. 

OFFERINGS configuration structure

As an example, let's configure an offering for Digital Transformation of existing applications into cloud-native ones. A block under 'OFFERINGS' section would need to be added to the WALDUR_SUPPORT section:

'DEFAULT_OFFERING_TYPE': 'Service Request',
	'offering_type': {
    	'label': 'Digital transformation',
        'category': 'Security',
		'article_code': '',  # article code is used for encoding product category in accounting software
        'product_code': '',  # technical code used by accounting software
    	'order': ['field_name2', 'field_name1'],
    	'options': {
         	'field_name1': {
             	'type': 'integer',
             	'label': 'Number of legacy applications',
             	'default': 1,
          	'field_name2': {
             	'type': 'string',
             	'label': 'Estimated deadline'
             	'help_text': 'Free form description when the project needs to be done'

Please note that article code and product code are optional fields. Maximum length of each field is 30 characters. If these fields are defined, they are copied from configuration to newly created offering.

Each field configured in 'options' must be present in the 'order' set otherwise an appropriate error will be raised. 

There are 4 pre-defined fields: project, name, description and type. Specifying any of them in configuration may lead to unexpected behavior.

  • Project field has to be referenced in a request as a URL link.
  • Name allows to redefine label of the offering to be displayed in Service Store.
  • Description will be added to the end of the issue description if provided.
  • Type which defines an offering type and a configuration section to read from. 

Field options


  • integer
  • string - considered to be default one and can be omitted.


Default value to use if field has not been provided in request.


Issue description. Considering configuration below a description of the issue will have the next format:

'Name': 'IT Transformation'
'Number of legacy applications' : '10'
'Estimated deadline': 'Deadline in May'
'Description': 'I would like to transform my applications into more cloud-enabled'

Please notice that 'Description' field is always placed on the bottom of the issue description.


A category name of the service. Used for grouping of services in Service Store.

Help Text

A description of a field that will be displayed in the form near a corresponding field. 

Example of creating a new request-based offering

For an offering configured as described above, the following API request would be accepted:

Sending POST request to the URL: with a body payload of:

'field_name1': '10', 
'field_name2': 'Deadline in May', 
'project': '', 
'name': 'IT Transformation',
'description': 'I would like to transform my applications into more cloud-enabled.',
'type': 'offering_type',

Issue type configuration

It is possible to configure a type of the issue by editing 'DEFAULT_OFFERING_TYPE' configuration. For instance, default type is configured to 'Service Request' as shown below:

'DEFAULT_OFFERING_TYPE': 'Service Request',
'OFFERINGS': { ... },

Default offering type is used as an issue type in a configured Helpdesk tool.


A total price for a particular offering is calculated based on the number of days the offering was in OK status, i.e. available for the end-user for consumption.

Lifecycle of a typical offering lifecycle is as follows:

  • Offering types are configured by operator of Waldur MasterMind.
  • User selects a service offering from a Service Store and submits a request. Request is created with a status of "Requested".
  • Operations fulfill the request.
  • A staff user defines price per day of the offering and updates it in the administrative panel of MasterMind and sets offering state to OK.
  • Accounting starts from the moment of setting the state to OK.
  • Accounting ends with a staff user setting offering state to Terminated.

Created offerings can be browsed in Support → HelpDesk → Offerings menu.

Price can be updated by clicking on required offering and setting price in the form that shows up.

Please notice that a price per day needs to be defined.

  • No labels