Due to a change in our Support and Release Policy this is crucial to ensure a working integration when upgrades introduce new functionality.

 These are simple ways to ensure things work through upgrades, and so that you only have to implement features that you want to.

Our Commitment

• The API itself will only in extremely rare cases change in specification
• Notifications will not be removed in minor versions, and in extremely rare cases in major versions (with consultation of integrators). 
• We place a huge emphasis on designing for the future, so we think things through as much as possible before work is done. 
• Changelogs will be issued with any required changes

Coding for the Unknown

There are things that can be done to make upgrades really really easy, often involving zero development effort on your part. 

New Types in the same Notification Channels

Add default cases for handling unknown types of notifications within the same channels, e.g. if we added a new agent notification for transfers then the type key would change.

//channel
//enigma:notifications:agents:1000

//Payload
{ 
    type: 'transfer', //this is the only part that you have not coded for, so its pretty safe to ignore this. 
    payload: {
        number: '0120001234',,
        call_ref: '168738',
        contact_ref: 'case_x45225',
        ref: 1000
    }
}

Basically just ignore them, and optionally log that an unknown notification type was received. (beware of log files growing large)

New Keys in the same Notification Types

ALL payloads are subject to change, keys won't easily be removed but new ones are very easily added, and you may not need them at all. 

This is mainly a warning for integrators who map payloads to classes, in that they should safely ignore or handle any new keys that they have not yet specifically coded for. 

//channel
//enigma:notifications:agents:1000

//Payload
{ 
    type: 'call', 
    payload: {
        number: '0120001234',,
        call_ref: '168738',
        contact_ref: 'case_x45225',
        ref: 1000,
        hold_time: 45 //here is a new key with the hold time for the callee, which you won't need, but may be useful
    }
}

New States for Agents or Campaigns 

This is probably the most difficult, for the most part we won't just add new states unless it conveys a real need for integrators to know that something in particular is in the process of occurring. 

Whenever a new state is introduced, it will specifically be mentioned in the Changelogs. 

The safest way to handle new states is to keep the previous state if the new one is not known. 

• Keep a list of supported states
• If the state is not supported, then do not change state. 
• Optionally log the unknown state (be careful of large log files)