Customizing Transactional Emails

Important. Much of the content on this page deals with a legacy feature of the Akamai Identity Cloud (in this case, the JavaScript SDK). If you are currently an Identity Cloud customer and are using the JavaScript SDK, that SDK is still supported. However, if you’re new to the Identity Cloud the JavaScript SDK is no longer available. Instead, you should use Hosted Login for your login and registration needs.

You can customize Akamai's transactional emails in many different ways. Here are a few suggestions:

How do I add or remove an email?

Adding or removing email templates is not supported in the Configuration API. Please contact your Akamai representative if you have additional questions.

How do I configure the sender address for transactional emails?

You may provide a custom sender email address from which any transactional emails will be sent to users. The default email sender if not customized is

You will need to complete a verification process to allow a new email address to be used by our Amazon SES service. The email address needs to be set up as a valid email address that will accept emails at least temporarily.

Akamai will request an Amazon-generated email to be sent to the address with a verification link that must be clicked within 24 hours. We will confirm with you when the verification email is generated, so if you do not see it immediately be sure to check if the email has been marked as SPAM. Once you have validated the email, you can disable the acceptance of emails if you choose.

Once that is complete, then you can add the email_sender_address setting to your API clients where you wish to use the sender address.

Tip, To limit the chances that your transactional emails end up in users' junk mail folders, see Help Prevent Transactional Emails from Being Labeled as Spam.

How can I send transactional emails through a third-party rather than Akamai?

Customers who wish to leverage their existing Email Service Provider (ESP) for implementing transactional email may do so by following the steps below.

Note. This assumes the ESP provides a mechanism for triggering emails via API.
  1. Identify the events that should trigger an email. See the Default Registration Experience Emails section above for the transactional emails that Akamai provides for a standard implementation.
  2. Add a handler to the Akamai onCaptureSaveSuccess JavaScript event to collect the form that was submitted and the email address that was input and send this data to your email service. For example, to send a confirmation email after registration, your event handler would look something like this:
        if(result.form == "registrationForm"){
          varemail = document.getElementById("capture_traditionalRegistration_emailAddress").value;
          // send "email" to your service and specify what email template to send
  3. If you wish to send an email when a user changes their email address, password, or another profile attribute, then Akamai will need to activate a webhook to notify you when the relevant attributes change for a user record. Akamai will need to know the URL of the service that will receive the webhook notification.
  4. Create an email service to run on your web server or other web accessible location. The service should support the following functions:
    • Process requests from the JS event handler to send emails.
    • Process requests from the webhook service, if applicable, to send emails.
  5. Retrieve additional profile data using the /entity API needed for inclusion in the email content. For example, the user’s first name for the email salutation.
  6.  Construct password reset URL by retrieving an authorization code using the /access/getAuthorizationCode API. Please note the following guidelines when making this call:
    1. The default expiration time for authorization codes is 30 seconds. To set the length of time that codes generated for password reset links are valid, include the time in seconds in the lifetime parameter of this call.
    2. The API client that is used to generate an authorization code must be the same as the API client that will be used to consume the code on your password reset page. Use the for_client_id parameter to specify which API client will be used to consume the code.
    3. The redirect_uri parameter must also match the value configured for the password_recover_url setting for the API client used to make this call.
  7.  Once you have generated a code, append it to your password reset link with ?code=<Generated Code>.
  8.  Construct an email verification URL by retrieving a verification code using the /access/getVerificationCode API. Please note the following guidelines when making this call:
  9. The default expiration time for verification codes is 7 days. To set the length of time that codes generated for email verification links are valid, include the time in seconds in the lifetime parameter of this call.
  10. The attribute_name parameter is used to specify what attribute will be updated with the current timestamp when the verification code is consumed, usually emailVerified.
  11. Initiate email sends with your ESP with the following details:
    • Recipient’s email address
    • Sender’s email address (optional)
    • What email to send
    • Password reset or email verification URL (required depending on email type)