Architecture

Integrating with Manifold requires building a thin integration layer which handles incoming HTTP requests from Manifold.

The following diagram illustrates the flow of requests between Manifold and your system:

Flow of requests between Manifold and your system.

The Provider API specification defines which endpoints need to be implemented on your end to complete your Manifold integration. The Connector API specification outlines endpoints which can be queried by your integration to gather more detail about resources and users.

Before starting your integration, here are a few core concepts.

Manifold Resource Model

Diagram highlighting how a Manifold Resource maps to a Product, a Plan and some Features.

  • A Service represents your managed service
  • Each Service maps to a Product sold in the Manifold catalog
  • Each Product has Plans which define the different tiers of service which can be purchased.
  • Users provision a Resource on Manifold which represents an instance of a Product for the chosen Plan

Resources and their Credentials

Credential sets (values, secrets, keys) are used by Manifold users to access a given Resource on the provider’s service.

Diagram of the relationship between Resource, their Credential sets and the Credential values.

Resource Ownership Model

Manifold manages resource access control through users and teams; because of this, resources can move as different access is granted to them.

Example scenario: An individual user may provision a resource and decide to share it with a team; at this juncture, the credentials and billing for the resource would change from the individual user to the team context. The original creator of the resource may lose access to the resource in question if they leave or are removed from the current team which owns the resource.

This ownership model enables uses to centrally manage access to resources across all products available on Manifold.

Recommendations when considering resource ownership in your database:

  • Create one umbrella entity (an account or a user depending on your system) for each provisioned resource. This entity should own the provisioned resource.
  • Do not associate the umbrella entity with a Manifold user, as ownership of the resource is subject to change.
  • Single Sign-on should enable a user to sign into the umbrella entity that owns the specified resource.
  • We recommend against mapping a Manifold user one-to-one with a user in your system.
  • The web dashboard for the provisioned resource should only be accessible through the Manifold single sign-on flow.
  • Do not keep a list of Manifold users having access to provisioned Resources; instead, use the Manifold Connector API to get that list when needed.

Next Step

In the following pages, we'll take a step-by-step approach to efficiently build your integration.

We cover the mandatory requests that all integrations must handle:

  • Provisioning of Resources
  • Deprovisioning of Resources
  • Provisioning of Credentials
  • Deprovisioning of Credentials
  • Resizing of Resources – Change plan

We also cover optional requests that only some integrations have to support based on the products and their configurations:

  • Single sign-on – Granting access to a web dashboard
  • Retrieval of Resource measures – For plans that have metered billing features

We will cover all of these from a high-level view. Detailed information on all API endpoints is available in the Provider API specification.