Why are Resource and Credential provisioned separately?

Over time, as Manifold evolves, we want to tackle the problem of credential management for both partners and developers. To achieve this, credentials must be a first class citizen of our platform by making them addressable so they can added, removed, and updated independently of the Resource life cycle.

Grafton already takes advantages of this in its credential rotation strategies right now.

What's the difference between the 'id' in the path and body of a 'PUT' request?

These values are identical. The id is provided in the body for completeness and convenience.

Which identifier should be used for reference?

All Resource and Credential IDs are globally unique and can be used for tracking internal data structures against their Manifold counterparts.

A Credential ID should only be used in relation to a set of Credentials (username and password or connection url) belonging to a Resource (e.g. a database instance).

What if my product does not have Credentials?

At the moment, Credentials are mandatory for every provisioned Manifold Resources.

With that said, we recognize that some Products (like those only exposing a Web Dashboard to Manifold users through Single sign-on) do not have the concept of credentials.

You can work around this restriction by returning Credentials that users do not have to use.

What if my product does not support regions?

For simplicity, a Resource will always have a region property. Products which do not support a region will receive the all::global region in the Provision request payload.

Do I have to build more than one integration if I have multiple products?

An integration can support multiple products. The Provider API sends a product label in the Resource provisioning request. That product label can be used for product specific logic.

When configuring your different products on Manifold, you should use the same integration URL for these products.

How can I get information about users with access to my Resource?

Manifold provides an endpoint (GET /resources/:id/users) on the Connector API to list users of a given resource and get their information. Details on that endpoint can be found in the Connector API documentation.

I have a different question

Anything not covered in the docs can be addressed by our provider success team who can be reached via [email protected] We will be happy to walk you through any questions you might have.

Grafton

What are the 'single' and 'multiple' credential types?

The credential types allow Grafton to determine if your product supports multiple live credential simultaneously or not.

• multiple credentials support means that your product can be accessed using different live credentials simultaneously.

• single credential support means that your product only supports one live credential at a time.

Grafton defaults to multiple since it offers the best experience to developers especially when performing a credential rotation.

What are the credential rotation tests?

The Grafton credential rotation tests ensure that the Credentials endpoints can be used to perform a rotation. Credential rotation is a process managed by Manifold that results in a new credential being used instead of the initial one.

Grafton will choose the best rotation strategy based on the type of credentials supported: single or multiple.

For single credentials, the initial credential is deleted first, and then a new one is created in its place. This is the replace strategy.

For multiple credentials, a new credential is created first, and then the old one gets deleted. This is the swap strategy.

Grafton also ensures that the initial and new credentials are different.