The templates endpoints manage notifications templates and notifications contents. Each content is based on one specific template. Each template can be associated with multiple contents.

Each environment has a set of predefined notifications templates it can access. A template represents a specific process flow, for example, device_pairing or strong_authentication, that requires a notification. Each template defines the deliveryMethods (Email, SMS, or Push) that it supports. You can read templates with this API, but you cannot create, update, or delete them.

A content defines one message text choice for a notification. Each content is always associated with one template and has one deliveryMethod and one locale. Each template comes with one predefined default content for each of its supported deliveryMethods. You cannot delete or update default contents with this API. You can however, create an unlimited number of custom contents for each template. To create custom contents, see Creating custom contents.

Runtime logic for content selection

Each content, whether default or custom, is associated with one template, one deliveryMethod, one locale, and optionally, one variant (For more information on variants, see Creating custom contents). When a request for content is executed at runtime, it includes a template, deliveryMethod, locale and , optionally, a variant.

1. PingOne looks for contents (default and custom) within the environment with an associated template and deliveryMethod that match the request’s template and deliveryMethod. The results are the pool of possible contents. The pool always includes one default content. Note that the default content has a locale that matches the Notifications settings defaultLanguage property. If defaultLanguage is not set, it defaults to en.

2. PingOne then looks at the request’s variant, if included. For more information about variant see Variants and Content properties. If the request includes a variant, all custom contents without a matching variant are discarded from the pool. The default content remains in the pool, although default contents never include a variant.

3. PingOne then looks at the contents’ locale. A locale can consist of an ISO language code only or it can consist of an ISO language code + a country code. For example, locale can be en for English or it can be en-GB for English (United Kingdom). The value of en is less specific. The value of en-GB is more specific.

   1. PingOne first tries to match the request’s locale to the locale of the custom contents in the pool.

      • If there is an exact match, that content is used for the notification. For example, the request’s locale is en and there is a content with the locale of en or the request’s locale is en-GB and there is a content with the locale of en-GB.
      • If there is no exact match and the request’s locale is less specific (en), PingOne looks for a more specific match. For example, a content with locale of en-GB. If found, that content is used for the notification. Otherwise, PingOne moves to step 3.2.
      • If there is no exact match and the request’s locale is more specific (en-GB), PingOne moves to step 3.2.
        
        

   2. PingOne next tries to match the Users property preferredLanguage to the locale of the custom contents in the pool.

      • If there is an exact match, that content is used for the notification. For example, preferredLanguage is en and there is a content with the locale of en or preferredLanguage is en-GB and there is a content with the locale of en-GB.
      • If there is no exact match and preferredLanguage is less specific (en), PingOne looks for a more specific match. For example, a content with locale of en-GB. If found, that content is used for the notification. Otherwise, PingOne moves to step 3.3.
      • If there is no exact match and preferredLanguage is more specific (en-GB), PingOne moves to step 3.3.
      • If preferredLanguage is not set, PingOne moves to step 3.3.
        
        

   3. PingOne finally tries to match the Notifications settings property defaultLanguage to the locale of the custom contents in the pool. If defaultLanguage is not set, it defaults to en.

      • If there is an exact match, that content is used for the notification. For example, defaultLanguage is en and there is a content with the locale of en or defaultLanguage is en-GB and there is a content with the locale of en-GB.
      • If there is no exact match and defaultLanguage is less specific (en), PingOne looks for a more specific match. For example, a content with locale of en-GB. If found, that content is used for the notification. Otherwise, the predefined default content is used for the notification.
      • If there is no exact match and defaultLanguage is more specific (en-GB), the predefined default content is used for the notification.

Creating custom contents

Add and update custom contents with POST /environments/{envID}/templates/{templateName}/contents and PUT /environments/{envID}/templates/{templateName}/contents/{contentID}. Each content is associated with one template and has one deliveryMethod and one ISO language code (locale). You can define multiple custom contents for each template + deliveryMethod + locale combination with the variant property.

Variants

If you have more than one custom content that uses the same template, deliveryMethod, and local, these contents must have different values for the variant property. The variant property holds the unique user-defined name for each content variant that uses the same template + deliveryMethod + locale combination.

variant values can be reused by contents across different template + deliveryMethod + locale combinations. They need to be unique within the same template + deliveryMethod + locale combination only. As a best practice, use the same variant value for contents with the same message text. For example, the variant value variant_A can be used by a content with the strong_authentication + email + en combination and also by a content with the strong_authentication + push + en combination. For two contents that both use the strong_authentication + email + en combination though, if one content uses the variant value of variant_A, the other content must use a variant value such as variant_B.

Use PATCH environments/{envID}/templates/{templateName}/contents?filter=variant eq {variantName} to bulk update the variant value in contents with the same variant value. Use DELETE environments/{envID}/templates/{templateName}/contents?filter=variant eq {variantName} to bulk delete contents with the same variant value.

Variables

Variables are placeholders for values that change dependiing on the context. For example:

• The SMS content is Hi ${user.username}! Your one time passcode is ${otp}.
• The ${user.username} variable has a value of John.
• The ${otp} variable has a value of 548263.

The resulting message is:
Hi John! Your one time passcode is 548263, which includes the variable values John and 548263.

Predefined variables

If a template includes predefined variables, the template lists which variables can be optionally used in its contents and which variables are required in its contents. For example, user.username can be optionally used by strong_authentication contents, while otp is required for all SMS and Email contents.

"variables": {
    "user.username": {
        "required": false
    },
    "otp": {
        "required": true,
        "requiredForDeliveryMethods": [
            "SMS",
            "Email"
        ]
    }
}

Dynamic variables

In addition to predefined variables, some templates also allow dynamic variables. If a template has the property allowDynamicVariables set to true, its contents can contain any user-defined variable in the format ${variable_name}. Define dynamic variables in the JSON Web Token (body.pi.template.variables) passed as the request body for GET /{envID}/as/authorize and POST /{envID}/as/authorize.

JWT: "header" :
{
  "alg": "HS256",
  "typ": "JWT"
},
"body" : 
{
  "aud": "https://auth.pingone.com/{envId}/as",
  "iss": "{applicationId}",
  "pi.template": {
    "name": "{templateName}",
    "variables": {
      "key1": "value1"
    }
  },
  "pi.clientContext": {
    "key2": "value2"
  }
}

Variable settings per template

Filtering result data

You can filter GET /environments/{envID}/templates and GET /environments/{envID}/templates/{templateName}/contents results by applying a SCIM filtering expression to the request URL. For large collections, a filtering expression appended to the query returns a targeted, more useful data set. For example, the following URL-encoded SCIM filter returns templates created before 2018-07-30 and updated after 2018-08-30:

[https://api.pingone.com/v1/environments/000c2764-3489-4d34-a707-b23dd488049c/templates?filter=(createdAt%20lt%20%222018-08-30%22)%20and%20(updatedAt%20gt%20%222018-07-30%22)%20](https://api.pingone.com/v1/environments/000c2764-3489-4d34-a707-b23dd488049c/templates?filter=(createdAt%20lt%20%222018-08-30%22)%20and%20(updatedAt%20gt%20%222018-07-30%22)%20)

SCIM operators can be applied to the following attributes:

Additionally, the logical and and or operators may be used for building compound expressions.

Ordering result data

You can order the collections returned by the GET collection endpoints according to the createdAt and updatedAt attribute. Ordering by any attribute returns the collection in a descending order. Using the attribute with the “-” prefix returns the collection ordered in ascending order. For example, the following URL returns all the templates ordered by ascending creation date:

[https://api.pingone.com/v1/environments/000c2764-3489-4d34-a707-b23dd488049c/templates?order=-createdAt](https://api.pingone.com/v1/environments/000c2764-3489-4d34-a707-b23dd488049c/templates?order=-createdAt)

For more information about SCIM syntax and operators, see Conventions.

Properties

Template Properties

Content Properties

Response codes