Candescent Create currently offers Developer Experience portals in the following world regions: North America (NAMER) Europe, the Middle East and Africa (EMEA) Asia-Pacific (APAC) North Asia-Pacific (NAPAC) Each of these regional portals operate independently of the others. For this reason, registering for a Candescent Create user account in one region will not grant you access to the others. If you need user access to multiple regions, you will need to follow the instructions to self-register in each and have each account separately provisioned.

API stands for Application Programming Interface. In simpler terms, an API is an interface that allows you to communicate with another piece of technology to obtain or send information. Here’s a helpful illustration: An API works like a company’s help desk. If you have a problem, you contact the help desk support team. Then you wait while they either find a solution for you or request more information. Once you have received what you need, you can take the necessary steps to fix your problem. The entire process is transactional; you either request or submit information.

The password expires every 90 days. Basic authentication utilizes a username and password to authenticate a request.

We live in an interconnected world in which data is abundant. You'll often want to access information from another service or company to integrate with your products with theirs. For example, perhaps you'd like to build a concert ticket-purchasing blockchain application. Obtaining information about artists and their concert schedules is essential an app like this one. Tracking down and contacting multiple artists or their agents is a cumbersome task. However, using an API developed by a company like StubMaster or Notify could provide this information without all the extra work, saving you time and resources. Suppose instead that you're creating an ecommerce website that sells gourmet cupcakes. Your goal is for interested consumers to log into your site to purchase the goodies. However, you would rather focus on baking than worry about managing customer information. Thankfully, there are APIs available that can manage the customer identity for you. For example, customers could log in using their social media profiles. With the right API, you could pull their identity and information from those accounts and keep the cupcake-buying process moving smoothly.

When generating a token that will provide an account with access to multiple organizations, the nep-oranization value in the token generation request must be the same as the value in the other request(s) where you will be using the token. For example, if you are generating a token to be used in subsequent requests to nep-organization margos-muffins, you will need to use the same header value in the request to generate the token. Using a token from a different organization in the header value in the subsequent request yields a 403 error.

No. Keys are only authorized to be used for the express purpose and system for which they have been provisioned. Utilize them only for their intended use and system. Once a shared and secret key pair provisioned for an Candescent customer or system are used elsewhere, that key pair is compromised from a security perspective. This means that every system using the keys must be rotated with a fresh, secure key pair. The compromised pair will need to be deactivated as soon as possible.

No. Once a shared and secret key pair provisioned for an CANDESCENT system are shared outside of CANDESCENT, that key pair is compromised from a security perspective. This means that every system using the keys must be rotated with a fresh, secure key pair. The compromised pair will need to be deactivated as soon as possible.

Secret and shared keys never expire. When using HMAC, you must create your own version of our algorithm and insert your secret and shared keys. To learn more about the HMAC method of authentication, check out the dedicated HMAC Examples GitHub.

No. Whenever a new pair of keys are generated, any previous keys for the user will still be valid.

Key pairs are specific to the system/user. Keys are used in place of basic auth credentials; when keys are used, the system sees that request as coming from a specific user. They're meant to only be used with the systems for which they were provisioned and should never be shared by customers, partners, or systems other than the ones for which they were specifically created.

No. Each secret/shared key pair must be used with its original counterpart. Secret and shared keys can't be separated or used in different combinations with other key pairs.

No.