Chassi Developer Hub

The Chassi Developer Hub

Welcome to the Chassi developer hub. You'll find comprehensive guides and documentation to help you start working with Chassi as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    API Reference

Getting Started with Lifecycle

In thirty minutes or less, we get you started! Let's go!

Lifecycle Kata

Now that you have Chassi, one of your main goals is to be able to get one of your customers on a Journey - Journey - An Entity being placed on a Lifecycle Step and continuing to track the Entity's progress of traversing the Lifecycle through various pathways. , change a Lifecycle Step - Lifecycle Step - An individual and discreet part of the business process defined in the Lifecycle. This can be a start step, in-progress step or terminal step. and track the progress of your Customer so you can begin to identify constraints and increase engagement.

With any Lifecycle - Lifecycle - A flowchart of steps in a business process with one or more outcomes, which collectively are called a Lifecycle. , you have one of two process goals. To keep a Customer in a Lifecycle as long as possible (e.g., customer adoption), or to get them through the Lifecycle as quickly as possible (e.g., onboarding process).

Purpose

Introduce Chassi's Customer Lifecycle product, together with Single Customer View. This Kata is aimed at getting you started quickly; first by performing a sample integration using a basic lifecycle, and then integrating your own unique Customer Lifecycle into your application and tracking your customers on it.

What you will Learn

This Exercise
Participants

Build the Lifecycle

Group

Publish the Lifecycle

Group

Wire Code to Each Lifecycle Step

Developer

Gather Data

n/a Application

Future Exercises

View Metrics & Understand Constraints / Performance

Group

Create Cycle Time and/or WIP Limit Thresholds

Group

Create Event Subscriptions using the Event Manager

Developer

Receive Cycle Time and/or WIP Limit Webhooks

Developer

Engage the Customer

Group

Group Activity

This activity is intended for both the Business Person (i.e., Product Manager) and Software Developer to work together, just like in a normal business setting where collaboration is important. The duration of this exercise estimates at less than 30 minutes. It is helpful if everyone participating in the effort can set aside the time and observe every part of the integration. If a facilitator is needed, we recommend that the developer facilitate this exercise. If performing this exercise remotely, the developer should perform screen sharing.

Overview

The Business Person (i.e., Product Manager) and the Software Developer will build the Lifecycle - Lifecycle - A flowchart of steps in a business process with one or more outcomes, which collectively are called a Lifecycle. together in the Chassi GUI. Every Lifecycle is built in the Definitional Space - Definitional Space - A Definitional Space in Chassi is like an Administration area and sometimes we use the terms Definitional and Admin interchangeably. Basically, the Definitional Space holds most of the configuration or definition of elements in our software. For example, the lifecycle process map, its versions, steps are all saved and managed in the Definitional Space. Think of definition as to where we "define" what something is, versus the other type of Application Space, which is Operational where we "operationalize" the definition. The Definitional Space is an Application Space which carries its own domain URI and object GUIDs. Each Application only has one Definitional Space, while it typically has many Operational Spaces. Data in the Definitional Space is published to an Operational Space in order to use it in Production, as an example. (i.e., Admin Space - Admin Space - If we ever refer to Admin Space, we mean Definitional Space. Admin Space is a synonym for Definitional Space, which is an Application Space. ) and published to an Operational Space - Operational Space - Before understanding Operational Space, it is helpful to first understand Definitional Spaces. If a Definitional Space is where you store the configuration of an Entity, the Operational Space is where you operationalize the Entity. For example, you will define a Customer Lifecycle in the Definitional Space, including its Lifecycle Steps and Lifecycle Versions and then you will publish it to an Operational Space. When you want to put a customer on a Journey on an Entity Lifecycle, that is done in any one of your Operational Spaces. Most Customer data and activity lives in Operational Spaces whereby configuration and definition live in the Definitional Space. The Operational Space(s) is an Application Space which carries its own domain URI and object GUIDs. As a rule of thumb, if the data has to do with a customer, you would typically interact in an Operational Space, like dev, stage, production or "Tom's Team" Application Spaces, otherwise, it will end up in the Definitional Space. (i.e., Sandbox, Stage, Production.)

Once published, the Software Developer will code the Lifecycle - Lifecycle - A flowchart of steps in a business process with one or more outcomes, which collectively are called a Lifecycle. into code fragments in the Customer's Application, inserting each Lifecycle Step - Lifecycle Step - An individual and discreet part of the business process defined in the Lifecycle. This can be a start step, in-progress step or terminal step. into the appropriate section of code in the Customer's Application and pointing at the target Operational Space - Operational Space - Before understanding Operational Space, it is helpful to first understand Definitional Spaces. If a Definitional Space is where you store the configuration of an Entity, the Operational Space is where you operationalize the Entity. For example, you will define a Customer Lifecycle in the Definitional Space, including its Lifecycle Steps and Lifecycle Versions and then you will publish it to an Operational Space. When you want to put a customer on a Journey on an Entity Lifecycle, that is done in any one of your Operational Spaces. Most Customer data and activity lives in Operational Spaces whereby configuration and definition live in the Definitional Space. The Operational Space(s) is an Application Space which carries its own domain URI and object GUIDs. As a rule of thumb, if the data has to do with a customer, you would typically interact in an Operational Space, like dev, stage, production or "Tom's Team" Application Spaces, otherwise, it will end up in the Definitional Space. for the given environment. The Customer is then moved through the Journey as a result of attaching each Lifecycle Step to potions of the application code which represent each step of the Lifecycle.

Progress is tracked automatically as the Customer triggers each Lifecycle Step - Lifecycle Step - An individual and discreet part of the business process defined in the Lifecycle. This can be a start step, in-progress step or terminal step. in the application, and the Business Person can generate report metrics in order to analyze performance. Once the performance is understood, then the Business Person and/or Developer can set thresholds for Cycle Time - Cycle Time - The total time from the beginning to the end of your process, as defined by you and your customer. Generally, we set a Cycle Time per Lifecycle Step - workflow stage. However, it is also acceptable to establish Cycle Time Limits over a range of Lifecycle Steps, as possible in the WIP Definitions feature. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action. and WIP Limit - WIP Limit - WIP is an acronym for "Work in Progress." Limiting WIP is to match a team or systems production capacity or load ability. Generally, we set a WIP limit per Lifecycle Step - workflow stage. However, it is also acceptable to establish limits over a range of Lifecycle Steps, as possible in the WIP Definitions feature. .

With the thresholds and limits set, the Software Developer can establish webhooks which authenticate over OAuth - OAuth - OAuth is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook, GitHub, and Chassi. OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. Basically, an OAuth exchange will provide the client (you) with a token, that you can use to authenticate with. The token expires after a certain period of time, and you must refresh it to get a new one. Think of it as a rotating API key. You will use OAuth to connect to the Chassi API, and we will use OAuth to connect to your application via webhook if you use webhooks. 2.0 to receive alerts and data from Chassi and program customer engagement tasks in their own application (e.g., initiate a process in Intercom or Salesforce.)

Concepts to Familiarize Yourself With

  • What is a Tenant - Tenant - A tenant in Chassi is a collection of Applications and Application Spaces within each Application. A Tenant is where your company operates and invites team members to work on an Application in an Application Space. A Tenant is both an operational and security barrier between other Tenants (other Chassi customers), and one Tenant cannot interact with another Tenant unless it has explicit permissions to do so. To provision a new Tenant, a new commercial license is subscribed to by a Chassi customer. The "Experiment" Tenant is also a Tenant; however, it is different in the organization of its application spaces and its limitations. It is not a "Production Tenant." It is not PCI or HIPAA compliant because of some shared components. A Tenant that creates from a Production Plan, however, is PCI and HIPAA compliant, known as a "Production Tenant." If you have an active membership to a Tenant, you will notice in the top of the Chassi UI, that you can switch between tenants. Users can belong to many tenants. ?
  • What is an Application Space - Application Space - An Application Space is modeled after an environment in your software development lifecycle. Application Spaces belong to an Application, and many organizations use Operational Application Spaces like dev, stage, and production. Others also use them as team environments or testing grounds. When you call an API in chassi, you are always calling it from a designated Application Space. There are two types of Application Spaces; (1) Definitional Space and (2) Operational Space. Sometimes we refer to the Definitional Space as an Admin Space. ?
  • What do we mean by Definitional Space - Definitional Space - A Definitional Space in Chassi is like an Administration area and sometimes we use the terms Definitional and Admin interchangeably. Basically, the Definitional Space holds most of the configuration or definition of elements in our software. For example, the lifecycle process map, its versions, steps are all saved and managed in the Definitional Space. Think of definition as to where we "define" what something is, versus the other type of Application Space, which is Operational where we "operationalize" the definition. The Definitional Space is an Application Space which carries its own domain URI and object GUIDs. Each Application only has one Definitional Space, while it typically has many Operational Spaces. Data in the Definitional Space is published to an Operational Space in order to use it in Production, as an example. ( Admin Space - Admin Space - If we ever refer to Admin Space, we mean Definitional Space. Admin Space is a synonym for Definitional Space, which is an Application Space. ) versus Operational Space - Operational Space - Before understanding Operational Space, it is helpful to first understand Definitional Spaces. If a Definitional Space is where you store the configuration of an Entity, the Operational Space is where you operationalize the Entity. For example, you will define a Customer Lifecycle in the Definitional Space, including its Lifecycle Steps and Lifecycle Versions and then you will publish it to an Operational Space. When you want to put a customer on a Journey on an Entity Lifecycle, that is done in any one of your Operational Spaces. Most Customer data and activity lives in Operational Spaces whereby configuration and definition live in the Definitional Space. The Operational Space(s) is an Application Space which carries its own domain URI and object GUIDs. As a rule of thumb, if the data has to do with a customer, you would typically interact in an Operational Space, like dev, stage, production or "Tom's Team" Application Spaces, otherwise, it will end up in the Definitional Space. ?
  • How do I authenticate using OAuth - OAuth - OAuth is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook, GitHub, and Chassi. OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. Basically, an OAuth exchange will provide the client (you) with a token, that you can use to authenticate with. The token expires after a certain period of time, and you must refresh it to get a new one. Think of it as a rotating API key. You will use OAuth to connect to the Chassi API, and we will use OAuth to connect to your application via webhook if you use webhooks. 2.0 for API transactions?
  • What is the API Spy - API Spy - The API Spy is a tool in our browser GUI that allows you to inspect every API request the UI is making. It contains the complete request and response payload, formatted specifically to help you understand how we are using the API in the Chassi UI. This is important because it contains all of the GUIDs we use to process transactions which will help you formulate your own requests. Additionally, when you are using the Chassi UI, you are actually calling your very own API. So if the UI calls a method, you can use that same method in your own application to call features. Chassi uses its own product to service its own customers, so when you are using the UI on Chassi, you are actually hitting all of your APIs just like you would from your own application. Except in this case, we have the Chassi UI hooked up to your API instead of your custom application. , and what do I use it for?

Chassi APIs use the OAuth - OAuth - OAuth is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook, GitHub, and Chassi. OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords. Basically, an OAuth exchange will provide the client (you) with a token, that you can use to authenticate with. The token expires after a certain period of time, and you must refresh it to get a new one. Think of it as a rotating API key. You will use OAuth to connect to the Chassi API, and we will use OAuth to connect to your application via webhook if you use webhooks. 2.0 protocol for authentication and authorization. Chassi supports common OAuth 2.0 scenarios such as those for a web server, installed, and client-side applications.

To begin, you will need a Service Account - Service Account - An OAuth 2.0 client credential used to authenticate to Chassi APIs. With this, a client (your application) can authenticate to the API without a static password. . As part of the Chassi Early Access program, we are distributing Service Accounts manually to each Tenant Owner - Tenant Owner - This is an owner application role. The Tenant Owner has the greatest permissions of all the roles and there can only be one Tenant Owner per Tenant. It has permissions which other roles cannot access, for example, adding or deleting a Tenant. . But in the future, Tenant Owner and Tenant Administrator - Tenant Administrator - This is an application administrator role. The Tenant Administrator is a role that is meant to assist the Tenant Owner in responsibilities since there can only be one Tenant Owner per Tenant. roles will be able to generate Service Accounts automatically from the API Manager - API Manager - A section in the Chassi GUI, available in the main navigation menu. The API Manager contains features that allow you to manage how Chassi APIs function, like enabling or disabling APIs, establishing service accounts, webhook credentials, etc. . If you do not have a Service Account, contact your Chassi Account Representative.

To learn how to use a service account in order to interact with a Chassi API, read the Authentication Service Account Quick Start.

What you will Need

  • Chassi user credentials for UI login
  • Chassi Service Account - Service Account - An OAuth 2.0 client credential used to authenticate to Chassi APIs. With this, a client (your application) can authenticate to the API without a static password. for your Experiment Tenant - Experiment Tenant - This is a type of Tenant which has its Definitional Space and Operational Space in the same GUID and DNS. There is no physical separation between the Application Spaces and the Experiment Tenant is not considered to be PCI nor HIPAA compliant due to the lack of physical separation of data. Every Chassi user receives a free Experiment Tenant which is intended to be used as a place to do API experiments or begin to build an Application until it warrants a Production Tenant meant for production use.
  • Personal Experiment Tenant - Experiment Tenant - This is a type of Tenant which has its Definitional Space and Operational Space in the same GUID and DNS. There is no physical separation between the Application Spaces and the Experiment Tenant is not considered to be PCI nor HIPAA compliant due to the lack of physical separation of data. Every Chassi user receives a free Experiment Tenant which is intended to be used as a place to do API experiments or begin to build an Application until it warrants a Production Tenant meant for production use.
  • Web Browser (We prefer Google Chrome)
  • Postman (download here) or cURL

Code Examples & Project Code

For ease of use, and realizing that not everyone has the same system set up, most of our examples will be done in Postman for which we will provide pre-configured scripts, available universally, regardless of platform, language, etc. cURL examples are provided for some snippets of API calls for reference purposes.


What's Next

Before you create your first Lifecycle and begin to put customers on a Journey, think about how you will integrate the customer into a Journey.

Thinking Ahead: Integration

Getting Started with Lifecycle


In thirty minutes or less, we get you started! Let's go!

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.