Transactions

Here are two ways to work with transactions : default or custom.

Most part of time, default transactions are suffisant, but if you have a specific need you can define your own transactions.

Note that the default compiler is not available with custom transactions. In other terms, i you wish define your own transactions, you will compile yourself your templates, or delegate the compilation to your API provider.

> Table of contents

• Default transactions
  • default
  • event.subscribe
  • event.unsubscribe
  • event.updated
  • user.bye
  • user.confirm
  • user.contact
  • user.invite
  • user.progress
  • user.survey
  • user.welcome
  • order.invoice
  • order.progress
  • order.shipped
  • password.request
  • password.updated
• Custom transactions

> Default transactions

There transactions working with any mode (api|smtp), and any compiler (provider|self|default).

The example payloads shown here are strictly required if you want to use the default build. If you compile your templates yourself or delegate the compilation to your API provider, you are obviously free to adapt these payloads to your needs.

default

He's used as fallback when you fire a non existing transaction, or intentionaly when you fire 'default'. This is useful if the message you need to send is short and conventional.

{
  user: { 
    username: String,
    email: String
  },
  message: String,
  cta: {
    label: String,
    link: String
  }
}

event.subscribe

Should be fired when a user subscribe to an event.

{
  user: { 
    username: String,
    email: String
  },
  message: String,
  cta: {
    label: String,
    link: String
  }
}

event.unsubscribe

Should be fired when a user unsubscribe from an event.

{
  user: { 
    username: String,
    email: String
  },
  message: String,
  cta: {
    label: String,
    link: String
  }
}

event.updated

Should be fired when an event is updated.

{
  user: { 
    username: String,
    email: String
  },
  message: String,
  cta: {
    label: String,
    link: String
  }
}

user.bye

Can be fired when a user close her account

{
  user: { 
    username: String,
    email: String
  },
  message: String,
  cta: {
    label: String,
    link: String
  }
}

user.confirm

Should be fired when a user must confirm her subscription.

{
  user: { 
    username: String,
    email: String
  },
  message: String,
  cta: {
    label: String,
    link: String
  }
}

user.contact

Should be fired when a user contact you, or when you contact a user.

{
  from: { 
    username: String,
    email: String
  },
  message: String,
  cta: {
    label: String,
    link: String
  }
}

user.invite

Should be fired when a user invite another user.

{
  from: { 
    username: String,
    email: String,
    picture?: String
  },
  message: String,
  cta: {
    label: String,
    link: String
  }
}

user.progress

Can be fired at each step of a complexe registration process.

{
  progress: Number,
  cta: {
    label: String,
    link: String
  }
}

user.survey

Can be fired when you wish ask an opinion about a particular subject.

{
  sentence: String,
  uri: String
}

user.welcome

Should be fired when a user has confirmed her subscription

{
  user: { 
    username: String,
    email: String
  },
  message: String,
  cta: {
    label: String,
    link: String
  }
}

order.invoice

Should be fired when you send an invoice to the customer.

{
  customer: { 
    name: String,
    street: String,
    zip: String,
    city: String,
    country: String,
    vat_number: String
  },
  order: {
    date: Date,
    reference: String
  },
  invoice: {
    without_vat: Number,
    vat_percentage: Number,
    vat_amount: Number,
    total: Number,
    currency: String
  },
  cta: {
    label: String,
    link: String
  }
}

order.progress

Should be fired when an order pass a step in your shipping process.

{
  order: {
    date: Date,
    reference: String,
    progress: Number
  },
  cta: {
    label: String,
    link: String
  }
}

order.shipped

Should be fired when the order has been delivered.

{
  customer: { 
    name: String,
    street: String,
    zip: String,
    city: String,
    country: String,
    vat_number: String
  },
  order: {
    date: Date,
    reference: String
  },
  cta?: {
    label: String,
    link: String
  }
}

password.request

Should be fired when a user request a new password (typicaly when he's forgotten her password).

{
  user: { 
    username: String,
    email: String
  },
  message: String,
  cta: {
    label: String,
    link: String
  }
}

password.updated

Should be fired as confirmation when user have modified her password.

{
  user: { 
    username: String,
    email: String
  },
  message: String,
  cta: {
    label: String,
    link: String
  }
}

> Custom transactions

The default compiler is not available with custom transactions. You will compile yourself your templates, or delegate the compilation to your API provider.

Map your template

If you compile yourself your template, skip this step.

Else, in cliamrc.js, as option of your transporter, add a template entry for your transaction:

{
  "options": {
      "templates": {
        "my.custom.transaction": "template-id"
      }
    }
}

Fire transaction and send email:

import { Cliam } from 'cliam';

// Do some stuffs ...
  
Cliam.mail('my.custom.event', data)
  .then(res => {
    console.log('Email has been delivered: ', res);
  })
  .catch(err => {
    console.log('Error while mail sending: ', err)
  });