Contacts

Contacts represent the customers that interact with your DC2 solution, but can also include people that are not directly customers, such as people who are related to the activities of customers (see Contact Associations for more on this).

OneBasket's contact system is tightly integrated with the SSO provider in use to ensure that a single source of truth for user details and authentication is maintained (i.e the SSO system).

There are a number of features built into OneBasket to ensure a robust and reliable experience for customers, solving a number of challenges that present themselves when building a system that aggregates data from multiple disparate provider systems, each of which generally have their own representation of the same customer.

In this section we'll introduce you to the concept of distributed identity, and the problems that arise from it. We'll walk you through the way the Contacts system is structured and works in OneBasket, and how it solves those problems. Then we'll discuss the features we have built on top of that to make contacts, and the relationships between them, extremely powerful.

📄️ Distributed Identity

In this problem domain, any given user can be represented across disparate systems, each with its own different user identifiers in use. For example, a ticketing system usually has its own representation of the user, as does a retail provider, and so on.

📄️ Contact Linking

To plug the holes that are generally left after SSO integrations take place, OneBasket has it's own contact linking mechanisms in place to ensure that the customer's identity can be unified across all provider system APIs.

📄️ Authorisation

OneBasket comes out of the box with an OIDC compliant authorisation mechanism, based on the present of a JWT bearer token in the header of the request.

📄️ Contact Associations

OneBasket comes out of the box with the ability to create "associations" between contacts.