Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More
Socket
Sign inDemoInstall
Socket

messagemedia-messages-sdk

Package Overview
Dependencies
Maintainers
1
Versions
7
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

messagemedia-messages-sdk

The MessageMedia Messages API provides a number of endpoints for building powerful two-way messaging applications.

  • 1.0.0
  • npm
  • Socket score

Version published
Weekly downloads
538
decreased by-41.65%
Maintainers
1
Weekly downloads
 
Created
Source

Getting started

The MessageMedia Messages API provides a number of endpoints for building powerful two-way messaging applications.

How to Build

The generated SDK relies on Node Package Manager (NPM) being available to resolve dependencies. If you don't already have NPM installed, please go ahead and follow instructions to install NPM from here. The SDK also requires Node to be installed. If Node isn't already installed, please install it from here

NPM is installed by default when Node is installed

To check if node and npm have been successfully installed, write the following commands in command prompt:

  • node --version
  • npm -version

Version Check

Now use npm to resolve all dependencies by running the following command in the root directory (of the SDK folder):

npm install

Resolve Dependencies

Resolve Dependencies

This will install all dependencies in the node_modules folder.

Once dependencies are resolved, you will need to move the folder MessageMediaMessages in to your node_modules folder.

How to Use

The following section explains how to use the library in a new project.

1. Open Project Folder

Open an IDE/Text Editor for JavaScript like Sublime Text. The basic workflow presented here is also applicable if you prefer using a different editor or IDE.

Click on File and select Open Folder.

Open Folder

Select the folder of your SDK and click on Select Folder to open it up in Sublime Text. The folder will become visible in the bar on the left.

Open Project

2. Creating a Test File

Now right click on the folder name and select the New File option to create a new test file. Save it as index.js Now import the generated NodeJS library using the following lines of code:

var lib = require('lib');

Save changes.

Create new file

Save new file

3. Running The Test File

To run the index.js file, open up the command prompt and navigate to the Path where the SDK folder resides. Type the following command to run the file:

node index.js

Run file

How to Test

These tests use Mocha framework for testing, coupled with Chai for assertions. These dependencies need to be installed for tests to run. Tests can be run in a number of ways:

Method 1 (Run all tests)

  1. Navigate to the root directory of the SDK folder from command prompt.
  2. Type mocha --recursive to run all the tests.

Method 2 (Run all tests)

  1. Navigate to the ../test/Controllers/ directory from command prompt.
  2. Type mocha * to run all the tests.

Method 3 (Run specific controller's tests)

  1. Navigate to the ../test/Controllers/ directory from command prompt.
  2. Type mocha MessagesController to run all the tests in that controller file.

To increase mocha's default timeout, you can change the TEST_TIMEOUT parameter's value in TestBootstrap.js.

Run Tests

Initialization

Authentication

In order to setup authentication in the API client, you need the following information.

ParameterDescription
basicAuthUserNameThe username to use with basic authentication
basicAuthPasswordThe password to use with basic authentication

API client can be initialized as following:

const lib = require('lib');

// Configuration parameters and credentials
lib.Configuration.basicAuthUserName = "basicAuthUserName"; // The username to use with basic authentication
lib.Configuration.basicAuthPassword = "basicAuthPassword"; // The password to use with basic authentication

Class Reference

List of Controllers

Class: MessagesController

Get singleton instance

The singleton instance of the MessagesController class can be accessed from the API Client.

var controller = lib.MessagesController;

Method: updateCancelScheduledMessage

Cancel a scheduled message that has not yet been delivered. A scheduled message can be cancelled by updating the status of a message from scheduled to cancelled. This is done by submitting a PUT request to the messages endpoint using the message ID as a parameter (the same endpoint used above to retrieve the status of a message). The body of the request simply needs to contain a status property with the value set to cancelled.

{
    "status": "cancelled"
}

Note: Only messages with a status of scheduled can be cancelled. If an invalid or non existent message ID parameter is specified in the request, then a HTTP 404 Not Found response will be returned

function updateCancelScheduledMessage(messageId, body, callback)
Parameters
ParameterTagsDescription
messageIdRequiredTODO: Add a parameter description
bodyRequiredTODO: Add a parameter description
Example Usage

    var messageId = 'messageId';
    var body = new CancelScheduledMessageRequest({"key":"value"});

    controller.updateCancelScheduledMessage(messageId, body, function(error, response, context) {

    
    });
Errors
Error CodeError Description
400TODO: Add an error description
404TODO: Add an error description

Method: getMessageStatus

Retrieve the current status of a message using the message ID returned in the send messages end point. A successful request to the get message status endpoint will return a response body as follows:

{
    "format": "SMS",
    "content": "My first message!",
    "metadata": {
        "key1": "value1",
        "key2": "value2"
    },
    "message_id": "877c19ef-fa2e-4cec-827a-e1df9b5509f7",
    "callback_url": "https://my.callback.url.com",
    "delivery_report": true,
    "destination_number": "+61401760575",
    "scheduled": "2016-11-03T11:49:02.807Z",
    "source_number": "+61491570157",
    "source_number_type": "INTERNATIONAL"
    "message_expiry_timestamp": "2016-11-03T11:49:02.807Z",
    "status": "enroute"
}

The status property of the response indicates the current status of the message. See the Delivery Reports section of this documentation for more information on message statues. Note: If an invalid or non existent message ID parameter is specified in the request, then a HTTP 404 Not Found response will be returned

function getMessageStatus(messageId, callback)
Parameters
ParameterTagsDescription
messageIdRequiredTODO: Add a parameter description
Example Usage

    var messageId = 'messageId';

    controller.getMessageStatus(messageId, function(error, response, context) {

    
    });
Errors
Error CodeError Description
404TODO: Add an error description

Method: createSendMessages

Submit one or more (up to 100 per request) SMS or text to voice messages for delivery. The most basic message has the following structure:

{
    "messages": [
        {
            "content": "My first message!",
            "destination_number": "+61491570156"
        }
    ]
}

More advanced delivery features can be specified by setting the following properties in a message:

  • callback_url A URL can be included with each message to which Webhooks will be pushed to via a HTTP POST request. Webhooks will be sent if and when the status of the message changes as it is processed (if the delivery report property of the request is set to true) and when replies are received. Specifying a callback URL is optional.
  • content The content of the message. This can be a Unicode string, up to 5,000 characters long. Message content is required.
  • delivery_report Delivery reports can be requested with each message. If delivery reports are requested, a webhook will be submitted to the callback_url property specified for the message (or to the webhooks) specified for the account every time the status of the message changes as it is processed. The current status of the message can also be retrieved via the Delivery Reports endpoint of the Messages API. Delivery reports are optional and by default will not be requested.
  • destination_number The destination number the message should be delivered to. This should be specified in E.164 international format. For information on E.164, please refer to http://en.wikipedia.org/wiki/E.164. A destination number is required.
  • format The format specifies which format the message will be sent as, SMS (text message) or TTS (text to speech). With TTS format, we will call the destination number and read out the message using a computer generated voice. Specifying a format is optional, by default SMS will be used.
  • source_number A source number may be specified for the message, this will be the number that the message appears from on the handset. By default this feature is not available and will be ignored in the request. Please contact support@messagemeda.com for more information. Specifying a source number is optional and a by default a source number will be assigned to the message.
  • source_number_type If a source number is specified, the type of source number may also be specified. This is recommended when using a source address type that is not an internationally formatted number, available options are INTERNATIONAL, ALPHANUMERIC or SHORTCODE. Specifying a source number type is only valid when the source_number parameter is specified and is optional. If a source number is specified and no source number type is specified, the source number type will be inferred from the source number, however this may be inaccurate.
  • scheduled A message can be scheduled for delivery in the future by setting the scheduled property. The scheduled property expects a date time specified in ISO 8601 format. The scheduled time must be provided in UTC and is optional. If no scheduled property is set, the message will be delivered immediately.
  • message_expiry_timestamp A message expiry timestamp can be provided to specify the latest time at which the message should be delivered. If the message cannot be delivered before the specified message expiry timestamp elapses, the message will be discarded. Specifying a message expiry timestamp is optional.
  • metadata Metadata can be included with the message which will then be included with any delivery reports or replies matched to the message. This can be used to create powerful two-way messaging applications without having to store persistent data in the application. Up to 10 key / value metadata data pairs can be specified in a message. Each key can be up to 100 characters long, and each value up to 256 characters long. Specifying metadata for a message is optional. The response body of a successful POST request to the messages endpoint will include a messages property which contains a list of all messages submitted. The list of messages submitted will reflect the list of messages included in the request, but each message will also contain two new properties, message_id and status. The returned message ID will be a 36 character UUID which can be used to check the status of the message via the Get Message Status endpoint. The status of the message which reflect the status of the message at submission time which will always be queued. See the Delivery Reports section of this documentation for more information on message statues. Note: when sending multiple messages in a request, all messages must be valid for the request to be successful. If any messages in the request are invalid, no messages will be sent.
function createSendMessages(body, callback)
Parameters
ParameterTagsDescription
bodyRequiredTODO: Add a parameter description
Example Usage

    var body = new SendMessagesRequest({    "messages": [        {            "callback_url": "https://my.callback.url.com",            "content": "My first message",            "destination_number": "+61491570156",            "delivery_report": true,            "format": "SMS",            "message_expiry_timestamp": "2016-11-03T11:49:02.807Z",            "metadata": {                "key1": "value1",                "key2": "value2"            },            "scheduled": "2016-11-03T11:49:02.807Z",            "source_number": "+61491570157",            "source_number_type": "INTERNATIONAL"        },        {            "callback_url": "https://my.callback.url.com",            "content": "My second message",            "destination_number": "+61491570158",            "delivery_report": true,            "format": "SMS",            "message_expiry_timestamp": "2016-11-03T11:49:02.807Z",            "metadata": {                "key1": "value1",                "key2": "value2"            },            "scheduled": "2016-11-03T11:49:02.807Z",            "source_number": "+61491570159",            "source_number_type": "INTERNATIONAL"        }    ]});

    controller.createSendMessages(body, function(error, response, context) {

    
    });
Errors
Error CodeError Description
400TODO: Add an error description

Back to List of Controllers

Class: DeliveryReportsController

Get singleton instance

The singleton instance of the DeliveryReportsController class can be accessed from the API Client.

var controller = lib.DeliveryReportsController;

Method: getCheckDeliveryReports

Check for any delivery reports that have been received. Delivery reports are a notification of the change in status of a message as it is being processed. Each request to the check delivery reports endpoint will return any delivery reports received that have not yet been confirmed using the confirm delivery reports endpoint. A response from the check delivery reports endpoint will have the following structure:

{
    "delivery_reports": [
        {
            "callback_url": "https://my.callback.url.com",
            "delivery_report_id": "01e1fa0a-6e27-4945-9cdb-18644b4de043",
            "source_number": "+61491570157",
            "date_received": "2017-05-20T06:30:37.642Z",
            "status": "enroute",
            "delay": 0,
            "submitted_date": "2017-05-20T06:30:37.639Z",
            "original_text": "My first message!",
            "message_id": "d781dcab-d9d8-4fb2-9e03-872f07ae94ba",
            "vendor_account_id": {
                "vendor_id": "MessageMedia",
                "account_id": "MyAccount"
            },
            "metadata": {
                "key1": "value1",
                "key2": "value2"
            }
        },
        {
            "callback_url": "https://my.callback.url.com",
            "delivery_report_id": "0edf9022-7ccc-43e6-acab-480e93e98c1b",
            "source_number": "+61491570158",
            "date_received": "2017-05-21T01:46:42.579Z",
            "status": "enroute",
            "delay": 0,
            "submitted_date": "2017-05-21T01:46:42.574Z",
            "original_text": "My second message!",
            "message_id": "fbb3b3f5-b702-4d8b-ab44-65b2ee39a281",
            "vendor_account_id": {
                "vendor_id": "MessageMedia",
                "account_id": "MyAccount"
            },
            "metadata": {
                "key1": "value1",
                "key2": "value2"
            }
        }
    ]
}

Each delivery report will contain details about the message, including any metadata specified and the new status of the message (as each delivery report indicates a change in status of a message) and the timestamp at which the status changed. Every delivery report will have a unique delivery report ID for use with the confirm delivery reports endpoint. Note: The source number and destination number properties in a delivery report are the inverse of those specified in the message that the delivery report relates to. The source number of the delivery report is the destination number of the original message. Subsequent requests to the check delivery reports endpoint will return the same delivery reports and a maximum of 100 delivery reports will be returned in each request. Applications should use the confirm delivery reports endpoint in the following pattern so that delivery reports that have been processed are no longer returned in subsequent check delivery reports requests.

  1. Call check delivery reports endpoint
  2. Process each delivery report
  3. Confirm all processed delivery reports using the confirm delivery reports endpoint Note: It is recommended to use the Webhooks feature to receive reply messages rather than polling the check delivery reports endpoint.
function getCheckDeliveryReports(callback)
Example Usage


    controller.getCheckDeliveryReports(function(error, response, context) {

    
    });

Method: createConfirmDeliveryReportsAsReceived

Mark a delivery report as confirmed so it is no longer return in check delivery reports requests. The confirm delivery reports endpoint is intended to be used in conjunction with the check delivery reports endpoint to allow for robust processing of delivery reports. Once one or more delivery reports have been processed, they can then be confirmed using the confirm delivery reports endpoint so they are no longer returned in subsequent check delivery reports requests. The confirm delivery reports endpoint takes a list of delivery report IDs as follows:

{
    "delivery_report_ids": [
        "011dcead-6988-4ad6-a1c7-6b6c68ea628d",
        "3487b3fa-6586-4979-a233-2d1b095c7718",
        "ba28e94b-c83d-4759-98e7-ff9c7edb87a1"
    ]
}

Up to 100 delivery reports can be confirmed in a single confirm delivery reports request.

function createConfirmDeliveryReportsAsReceived(body, callback)
Parameters
ParameterTagsDescription
bodyRequiredTODO: Add a parameter description
Example Usage

    var body = new ConfirmDeliveryReportsAsReceivedRequest({    "delivery_report_ids": [        "011dcead-6988-4ad6-a1c7-6b6c68ea628d",        "3487b3fa-6586-4979-a233-2d1b095c7718",        "ba28e94b-c83d-4759-98e7-ff9c7edb87a1"    ]});

    controller.createConfirmDeliveryReportsAsReceived(body, function(error, response, context) {

    
    });
Errors
Error CodeError Description
400TODO: Add an error description

Back to List of Controllers

Class: RepliesController

Get singleton instance

The singleton instance of the RepliesController class can be accessed from the API Client.

var controller = lib.RepliesController;

Method: createConfirmRepliesAsReceived

Mark a reply message as confirmed so it is no longer returned in check replies requests. The confirm replies endpoint is intended to be used in conjunction with the check replies endpoint to allow for robust processing of reply messages. Once one or more reply messages have been processed they can then be confirmed using the confirm replies endpoint so they are no longer returned in subsequent check replies requests. The confirm replies endpoint takes a list of reply IDs as follows:

{
    "reply_ids": [
        "011dcead-6988-4ad6-a1c7-6b6c68ea628d",
        "3487b3fa-6586-4979-a233-2d1b095c7718",
        "ba28e94b-c83d-4759-98e7-ff9c7edb87a1"
    ]
}

Up to 100 replies can be confirmed in a single confirm replies request.

function createConfirmRepliesAsReceived(body, callback)
Parameters
ParameterTagsDescription
bodyRequiredTODO: Add a parameter description
Example Usage

    var body = new ConfirmRepliesAsReceivedRequest({    "reply_ids": [        "011dcead-6988-4ad6-a1c7-6b6c68ea628d",        "3487b3fa-6586-4979-a233-2d1b095c7718",        "ba28e94b-c83d-4759-98e7-ff9c7edb87a1"    ]});

    controller.createConfirmRepliesAsReceived(body, function(error, response, context) {

    
    });
Errors
Error CodeError Description
400TODO: Add an error description

Method: getCheckReplies

Check for any replies that have been received. Replies are messages that have been sent from a handset in response to a message sent by an application or messages that have been sent from a handset to a inbound number associated with an account, known as a dedicated inbound number (contact support@messagemedia.com for more information on dedicated inbound numbers). Each request to the check replies endpoint will return any replies received that have not yet been confirmed using the confirm replies endpoint. A response from the check replies endpoint will have the following structure:

{
    "replies": [
        {
            "metadata": {
                "key1": "value1",
                "key2": "value2"
            },
            "message_id": "877c19ef-fa2e-4cec-827a-e1df9b5509f7",
            "reply_id": "a175e797-2b54-468b-9850-41a3eab32f74",
            "date_received": "2016-12-07T08:43:00.850Z",
            "callback_url": "https://my.callback.url.com",
            "destination_number": "+61491570156",
            "source_number": "+61491570157",
            "vendor_account_id": {
                "vendor_id": "MessageMedia",
                "account_id": "MyAccount"
            },
            "content": "My first reply!"
        },
        {
            "metadata": {
                "key1": "value1",
                "key2": "value2"
            },
            "message_id": "8f2f5927-2e16-4f1c-bd43-47dbe2a77ae4",
            "reply_id": "3d8d53d8-01d3-45dd-8cfa-4dfc81600f7f",
            "date_received": "2016-12-07T08:43:00.850Z",
            "callback_url": "https://my.callback.url.com",
            "destination_number": "+61491570157",
            "source_number": "+61491570158",
            "vendor_account_id": {
                "vendor_id": "MessageMedia",
                "account_id": "MyAccount"
            },
            "content": "My second reply!"
        }
    ]
}

Each reply will contain details about the reply message, as well as details of the message the reply was sent in response to, including any metadata specified. Every reply will have a reply ID to be used with the confirm replies endpoint. Note: The source number and destination number properties in a reply are the inverse of those specified in the message the reply is in response to. The source number of the reply message is the same as the destination number of the original message, and the destination number of the reply message is the same as the source number of the original message. If a source number wasn't specified in the original message, then the destination number property will not be present in the reply message. Subsequent requests to the check replies endpoint will return the same reply messages and a maximum of 100 replies will be returned in each request. Applications should use the confirm replies endpoint in the following pattern so that replies that have been processed are no longer returned in subsequent check replies requests.

  1. Call check replies endpoint
  2. Process each reply message
  3. Confirm all processed reply messages using the confirm replies endpoint Note: It is recommended to use the Webhooks feature to receive reply messages rather than polling the check replies endpoint.
function getCheckReplies(callback)
Example Usage


    controller.getCheckReplies(function(error, response, context) {

    
    });

Back to List of Controllers

Keywords

FAQs

Package last updated on 23 Nov 2017

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap
  • Changelog

Packages

npm

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc