Multitech MTR-H5, MTR-C2, MTR-H6, MTR-G3, MTR-EV3 Developer's Manual

...
MultiConnect
Developer Guide
R
rCell API
Copyright and Technical Support
MultiConnect
rCell API Developer Guide Models: MTR-H5, MTR-H6, MTR-G3, MTR-EV3, MTR-C2 (Software Version 3.0.9) S000576, Version 1.0
Copyright
This publication may not be reproduced, in whole or in part, without prior expressed written permission from Multi-Tech Systems, Inc. All rights reserved. Copyrightc 2014, by Multi-Tech Systems, Inc. Multi-Tech Systems, Inc. makes no representations or warranties with respect to the contents hereof and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose. Furthermore, Multi-Tech Systems, Inc. reserves the right to revise this publication and to make changes from time to time in the content hereof without obligation of Multi-Tech Systems, Inc. to notify any person or organization of such revisions or changes. Check Multi-Techs web site for current versions of our product documentation.
Revision History
Revision Date Author Description
0.1 1/4/13 Jason Reiss Initial Document
0.2 1/30/13 Jason Reiss Auto-Gen Script and Reference Updates
0.3 2/27/13 Jason Reiss Removed Unused Elements
0.4 3/11/13 Jason Reiss Updated Logout Instructions
0.5 6/1/13 Sean Godinez Updated Auto-Gen Scripts and Document Content
0.6 6/6/13 Sean Godinez Added Statistics and Help Section
0.7 11/21/13 Sean Godinez Updated for rCell v3.0.9
0.8 12/2/13 Sean Godinez Added ’DRAFT’ Watermark
0.9 12/4/13 Jason Reiss Updated document layout
1.0 1/15/14 Sean Godinez Release
Trademarks
Multi-Tech Registered Trademarks: MultiConnect, Multi-Tech, and the Multi-Tech logo. All other products and technologies are the trademarks or registered trademarks of their respective holders.
Contacting Multi-Tech
Knowledge Base
The Knowledge Base provides immediate access to support information and resolutions for all Multi-Tech products. Visit http://www.multitech.com/kb.go.
Installation Resources
To download manuals, firmware, and software, visit http://www.multitech.com/setup/product.go.
Support Portal
To create an account and submit a support case directly to our technical support team, visit: https://support.multitech.com.
Technical Support
Business Hours: M-F, 9am to 5pm CST
Country By Email By Phone
Europe, Middle East, Africa: support@multitech.co.uk +(44) 118 959 7774
U.S., Canada, all others: support@multitech.com (800) 972-2439 or (763) 717-5863
World Headquarters
Multi-Tech Systems, Inc. 2205 Woodale Drive Mounds View, MN 55112 United States Phone: 800-328-9717 or 763-785-3500 Fax: 763-785-9874
Warranty
To read the warranty statement for your product, please visit: http://www.multitech.com/warranty.go.
2 Multi-Tech Systems, Inc. MultiConnect
R
rCell API Developer Guide
CONTENTS
Contents
1 Introduction 5
2 Requests 5
2.1 Making Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Logging In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Logging Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Who Am I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Passing JSON Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Saving Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.7 Selecting a Version of an API Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.8 Element Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.9 URI Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Responses 10
3.1 Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 Success response format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Error response format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Commands and Collections 12
4.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Collection Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.1 autoDialout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.2 autoReboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.3 bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.4 brand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.5 ddns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.6 devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.7 dhcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.8 dns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.9 filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.10 gccp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.11 gps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.12 greTunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.13 ipPipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.14 ipsecTunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.15 lan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.16 nat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.17 networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.18 ppp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.19 remoteAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.20 remoteManagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.21 routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.22 serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.23 sntp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.24 syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.25 system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.26 users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.27 wifi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Multi-Tech Systems, Inc. MultiConnect
R
rCell API Developer Guide 3
CONTENTS
5 Statistics 28
5.1 dns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 gps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 gre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4 ipsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.5 lan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.6 modbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.7 ppp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.8 serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.9 service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.10 wlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6 Appendix 34
6.1 REST Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 JSON Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3.1 Using Curl to log in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3.2 Using Curl to enable PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.3.3 Using Curl to add a firewall DNAT rule . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3.4 Using Curl to add a firewall filter rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3.5 Using Curl to delete a firewall filter rule by name . . . . . . . . . . . . . . . . . . . . . . 37
6.3.6 Using Curl to delete a firewall filter rule by index . . . . . . . . . . . . . . . . . . . . . . 37
6.3.7 Using Curl to save current configurations and reboot . . . . . . . . . . . . . . . . . . . . 37
4 Multi-Tech Systems, Inc. MultiConnect
R
rCell API Developer Guide
2 REQUESTS
1 Introduction
R
The MultiConnect
rCell is a cellular router that uses a RESTful JSON API for managing configurations, polling statistics, and issuing commands. This document provides information on the design, patterns, and methods within the rCell API. The Appendix of this document has additional information for those unfamiliar with the REST architecture or JSON data format. For additional examples and use-cases, explore the JavaScript within the rCell website, specifically https://[rcell ip]/js/api.js.
2 Requests
All API requests will be directed to the https://[rcell ip]/api url. The majority of requests follow the same RESTful pattern. Following the api url will be a collection name or a command directive. For example, information on the current DHCP settings can be found in the DHCP collection at https://[rcell ip]/api/dhcp. A full list of collections and commands can be found in section 4. For all examples in this document, the rCell’s IP address is
192.168.2.1.
2.1 Making Requests
The RESTful interface allows users to retrieve data, add data, update data, and delete data using call methods: GET, POST, PUT and DELETE, respectively. These methods can be set in the HTTP header, or they can be set in the URI using the key: method. Using the URI parameter method is a useful way to execute RESTful requests through a web browser. Additional URI parameters can be found in section 2.9 URI Parameters.
All API requests return a JSON object. The JSON response will always contain the members code and status. The status member indicates a high-level result of the request and has two possible values: success and fail. The code member is an HTTP response code describing the outcome of the API result. For a full list of response code values, see section 3.2.2 Error Codes.
If an API call was successful, it may contain the member: result. This member contains data that was either requested or data that was generated as part of the API request. If an API call was unsuccessful, the JSON response will contain the member error. This member is a short description of the failure.
Example: Retrieving the current DHCP setting using the method URI parameter.
1 G ET https://192.168.2.1/api/dhcp?method=GET 2 3 S t a tus : HTT P /1. 1 2 00 OK 4 { 5 " c ode " : 2 0 0 , 6 " r e sult " : { 7 " de f a u l t G a t e way " : "192 . 1 6 8 . 2 . 1 " , 8 " d o m a i n " : "" , 9 " e n a b l e d " : tr u e ,
10 " fi x e d A d d r e s ses " : [ 11 { 12 " ip" : "1 9 2 . 1 6 8 . 2.15" , 13 " ma c " : " 0 0 : 1 A : 1 2 : 1 9 : 3 F : 60 " 14 } 15 ] , 16 " l e a s e T i m e " : 864 0 0 , 17 " l e a s e s " : [ 18 { 19 " e x p i ration " : 70 359 , 20 " h o s tName " : " my - p c " , 21 " ip" : "1 9 2 . 1 6 8 . 2 .103" ,
Multi-Tech Systems, Inc. MultiConnect
R
rCell API Developer Guide 5
2 REQUESTS
22 " ma c " : " 0 0 : 3 a : 8 3 : 1 0 : 2 4 : DC " 23 } 24 ] , 25 " m a x L e a s e s " : 20 0 , 26 " o p t i o n s " : [ " d hcp - au t h o r i t a t i v e " ] , 27 " r a n g e E n d " : "192.16 8 . 2 . 2 5 4 " , 28 " ra n g e S t art " : "19 2 . 1 6 8 . 2 . 1 0 0 " , 29 " su b n e t A d d r ess " : "192. 1 6 8 . 2 . 0 " , 30 " su b n e t M ask " : "25 5 . 2 5 5 . 2 5 5 . 0 " 31 }, 32 " s t atus " : " su c c e ss " 33 }
The API allows requests to path to specific elements or groups of embedded elements. For example, if a user only wanted to know if DHCP was enabled, they could make the request: https://[rcell ip]/api/dhcp/enabled.
Example: Path to an element within the DHCP collection.
1 G ET https://192.168.2.1/api/dhcp/enabled 2 3 S t a tus : HTT P /1. 1 2 00 OK 4 { 5 " c ode " : 2 0 0 , 6 " r e sult " : t r u e , 7 " s t atus " : " su c c e ss " 8 }
Accessing objects within an array can be done using the index of the desired object in the path. Some collections support using an object’s unique identifier in place of the object’s index; generally, this unique identifier is a member called name or guid. For example, suppose an rCell was configured with a GRE tunnel named MyGreTunnel, and a user wanted to know the IP address of the remote end point of that tunnel. The user could make a RESTful GET request to https://[rcell ip]/api/greTunnels/MyGreTunnel/remoteIp.
Example: Path to an element within an object in an array using the object’s unique identifier.
1 G ET https://192.168.2.1/api/greTunnels/MyGreTunnel/remoteIp 2 3 S t a tus : HTT P /1. 1 2 00 OK 4 { 5 " c ode " : 2 0 0 , 6 " r e sult " : "1 6 6 . 1 8 4 .38.73" , 7 " s t atus " : " su c c e ss " 8 }
2.2 Logging In
To use the API, a user must be authorized and have equal or greater privileges than the API call they are invoking. A user can login with valid credentials by passing their username and password to the login URL ( https://192.168.2.1/api/login ) either as URI parameters or within a JSON object. The following call will login the user admin, and return the session information including an authorized token. The API attempts to cache the token as a cookie in the user’s web browser for authorizing future calls. As an alternative to using a browser cookie, this token can be passed as a URI parameter using the key: token. Additional URI parameters can be found in section 2.9 URI Parameters.
Example: Login using username ’admin’ and password ’admin’.
1 G ET https://192.168.2.1/api/login?username=admin&password=admin 2 3 S t a tus : HTT P /1. 1 2 00 OK
6 Multi-Tech Systems, Inc. MultiConnect
R
rCell API Developer Guide
2 REQUESTS
4 { 5 " c ode " : 2 0 0 , 6 " r e sult " : { 7 " a d d r e s s " : "192.16 8 . 2 . 1 0 3 " , 8 " pe r m i s s ion " : "ad m i n " ,
9 " p o r t " : "5 9 4 8 6 " , 10 " t i m e s t a m p " : "2 : 58 : 4 0 : 38 9 " , 11 " t o k e n " : "B7083A0B14C0F0BEFFBE D 8 9 B 9 9 E F B C ", 12 " u s e r " : "ad m i n " 13 }, 14 " s t atus " : " su c c e ss " 15 }
A token may timeout due to inactivity. The timeout configuration is in the rCell’s Remote Access collection ( api/remoteAccess/timeoutSeconds ). There are two authorizers, one for website access and one for non-web browser usage, such as command line utilities like wget and curl. The same user can not be logged in through the same authorizer from more than one IP address. If a user is already logged in and attempts to login from another IP address, a conflict error will be returned. A user can logout from any IP address with the proper credentials.
2.3 Logging Out
The logout call requires that the caller has equal or greater permissions than the user they are logging out. If a user wants to logout, they can pass their authorized token in the following call:
Example:. https://192.168.2.1/api/logout?token=ABCDEF1234567890ABCDEF12345678
To logout another user (guest), a user with equal or greater permissions can use their token to authorize the call:
Example: https://192.168.2.1/api/logout?logoutUser=guest&token=ABCDEF1234567890ABCDEF12345678
Credentials can also be passed with the logout command to authorize the logout call of another user:
Example: https://192.168.2.1/api/logout?username=admin&password=admin&logoutUser=guest
2.4 Who Am I
At any point, a user can retrieve their session information using the following API call:
Example:
1 G ET https://192.168.2.1/api/whoami
2
3 S t a tus : HTT P /1. 1 2 00 OK
4 {
5 " c ode " : 2 0 0 ,
6 " r e sult " : {
7 " a d d r e s s " : "192.16 8 . 2 . 1 0 3 " ,
8 " pe r m i s s ion " : "ad m i n " ,
9 " p o r t " : "5 9 4 8 6 " , 10 " t i m e s t a m p " : "2 : 58 : 4 0 : 38 9 " , 11 " t o k e n " : "B7083A0B14C0F0BEFFBE D 8 9 B 9 9 E F B C ", 12 " u s e r " : "ad m i n " 13 }, 14 " s t atus " : " su c c e ss " 15 }
Multi-Tech Systems, Inc. MultiConnect
R
rCell API Developer Guide 7
2 REQUESTS
2.5 Passing JSON Data
Data can be sent to the rCell by passing a JSON object as the request content or by passing a JSON object in the URI parameter: data. As an example, the following request uses a RESTful PUT call to edit the current DHCP configurations by passing in a JSON object with the enabled member set to false
Example: To disable DHCP, send the following request:
https://192.168.2.1/apidhcp?data={"enabled":false}&method=PUT
2.6 Saving Changes
A call to save ( https://[rcell ip]/command/save ) will write current changes to the device settings. Commands are executed using RESTful POST requests. A full list of commands can be found in section 4.1 Commands.
Example: To save the current changes, send a request to:
https://192.168.2.1/api/command/save?method=POST
2.7 Selecting a Version of an API Call
As the rCell API evolves and new features are added, backwards compatibility can be maintained by setting the desired API version within the request. The API version can be set through the version URI parameter, or through the URL path by subscripting the version number with the letter ’v’. If a request has only one version, this value is ignored.
Example: To use version 1 of the API, all API requests would be made through https://[rcell ip]/api/v1/[request path] or https://[rcell ip]/api/[request path]?version=1. If a version is not specified, the request will be executed using the latest API version.
2.8 Element Descriptions
The API provides documentation on collections and elements through https://[rcell ip]/api/help. For a description of an element or group of elements, use the path to retrieve the data and prepend help to the collection component. For example, if a user wanted information on the DHCP element enabled ( https://[rcell ip]/api/dhcp/enabled ), they could submit a RESTful GET request to https://[rcell ip]/api/help/dhcp/enabled.
Example: Retrieving a description of the DHCP member enabled.
1 G ET https://192.168.2.1/api/help/dhcp/enabled
2
3 S t a tus : HTT P /1. 1 2 00 OK
4 {
5 " c ode " : 2 0 0 ,
6 " r e sult " : {
7 " dh c p _ e n a b led " : "en a b l e or disa b l e D H C P s erver ( de f a u l t : tr u e ) : BO O L "
8 },
9 " s t atus " : " su c c e ss " 10 }
The API also provides a separate set of help descriptions that are used by the rCell website for context-sensitive help-on-hover content. The path to each description follows the menu and category embedding of the rCell website.
8 Multi-Tech Systems, Inc. MultiConnect
R
rCell API Developer Guide
2 REQUESTS
Example: Retrieving a more human-readable description of the DHCP member enabled.
1 G ET https://192.168.2.1/api/help/Setup/DHCP/Settings/Enabled
2
3 S t a tus : HTT P /1. 1 2 00 OK
4 {
5 " c ode " : 2 0 0 ,
6 " r e sult " : {
7 " Se t u p _ D H C P _ S e t t i n g s _ E n a b l e d " : " Chec k t o use a DHCP serv e r o n n etwor k "
8 },
9 " s t atus " : " su c c e ss " 10 }
2.9 URI Parameters
URI parameters are reserved keys that are used to modify the functionality of API calls, override HTTP header values, and bundle multiple API requests together. Below is a list of available URI keys and descriptions of their functionality.
URI Key Description
fields Applies a RESTful action to multiple collections/elements. Each request path is separated by a comma. Requested
data within a field is returned using the path by replacing ’/’ characters with ’ ’ characters.
Example:
1 G ET https://192.168.2.1/api?fields=lan/ip, serial/client/enabled&method=GET 2 3 S t a tus : HTT P /1. 1 2 00 OK 4 { 5 " c ode " : 2 0 0 , 6 " r e sult " : { 7 " l a n _ i p " : "192. 1 6 8 . 2 . 1 " , 8 " se r i a l _ c l i e n t _ e n a b l e d " : fal s e 9 },
10 " s t atus " : " su c c e ss " 11 }
method Allows passing RESTful action (GET, PUT, POST, & DELETE) in URI. This overrides the HTTP header method.
See section 2.1
apply Allows the request to be applied at the given timestamp without restarting. Currently, only apply=now is
supported.
token Authorized Login Token. This can be passed to authorize an API call. A token is returned upon a successful
login. If a user is logged in, the whoami request will return the users current token. See section 2.2
inactivity Allows requests to be made without bumping the user’s token expiration date. This is useful for automated polling
loops that still want to allow a user to timeout due to inactivity (inactivity=true)
session Reserved for internal use. This member will be overwritten.
data Allows passing a JSON Object in the URI.
default This option will retrieve the factory defaults of a collection when using a RESTful GET request, and set a collection
to its factory defaults when using a RESTful PUT request. (default=true)
version Sets the API version to use during the request. See section 2.7
username User’s login name. Used for logging into the API. See section 2.2
password User’s login password. Used for logging into the API. See section 2.2
logoutUser User to be logged out. Only used on api/logout request. See section 2.3
R
Multi-Tech Systems, Inc. MultiConnect
rCell API Developer Guide 9
3 RESPONSES
3 Responses
All API requests return a JSON object. The JSON response will always contain the members code and status. The status member indicates a high-level result of the request and has two possible values: success and fail. The code member is a HTTP response code describing the outcome of the API result. Certain actions or events in the API may result in a URL redirect, such as trying to access API methods when a user is not logged in. In these situations, the JSON response may contain the member referrer.
3.1 Success
In the event of a successful request a success message will be returned with the member status set to success and code set to 200. If data is sent in the response it will be found in the result field.
3.1.1 Success response format
1 S t a tus : HTT P /1. 1 2 00 OK
2 {
3 " c ode ": 20 0 ,
4 " s t atus ": "suc c e s s " ,
5 " r e sult ": { [ J S O N O b ject or Arr a y ] }
6 }
3.2 Error
An error response will always contain the members: code, status, and error. If an error is encountered during a request, the API will halt processing and return an error message. This means that a request with multiple errors will receive a response containing error information on only the first error that the API finds during the processing of that request.
3.2.1 Error response format
1 S t a tus : HTT P /1. 1 [ E r r or Code ] [ Er r o r M e s s age ]
2 {
3 " c ode ": [Er r o r C ode ] ,
4 " s t atus ": "fa i l " ,
5 " e rror ": "[ Er r o r M e ssage ]"
6 }
10 Multi-Tech Systems, Inc. MultiConnect
R
rCell API Developer Guide
3 RESPONSES
3.2.2 Error Codes
Code Error
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
408 Request Timeout
409 Conflict
500 Internal Server Error
501 Not Implemented
Multi-Tech Systems, Inc. MultiConnect
R
rCell API Developer Guide 11
4 COMMANDS AND COLLECTIONS
4 Commands and Collections
4.1 Commands
The API supports a set of special actions through the Command URL ( api/command ). To execute a command, the call method must be a POST request. A RESTful GET request will return an array of all of the commands.
Command Description Parameters
firmware upgrade Upgrades rCell firmware upgrade file
legacy sync Synchronizes legacy configurations
restart Restarts rCell device
revert Reverts all changes since the last save
save Saves the current configurations
ddns update Pushes DDNS information to the configured DDNS server
download config Downloads the current configurations
loglvl debug Sets the API’s logging level to DEBUG
loglvl info Sets the API’s logging level to INFO
loglvl trace Sets the API’s logging level to TRACE
loglvl warning Sets the API’s logging level to WARNING
radio cmd Send a string directly to the cellular radio
1 { 2 " at": [ A T C O M M AND ] , 3 " t i meout ": [milli s e c o n d s ] 4 }
JSON Data
remove icon Deletes user-supplied icon
remove image Deletes user-supplied image
remove logo Deletes user-supplied logo
reset bluetooth Resets the Bluetooth hardware
reset modem Resets the cellular radio hardware
reset wifi Resets the WiFi hardware
restore defaults Resets the rCell with User-Defined defaults if set, otherwise factory
restore factory Resets the rCell with factory defaults
clean oem Clears User-Defined default configurations returning factory default
save oem Saves current configurations as factory/OEM defaults
save restart Saves the current configurations and restarts the rCell
telit upgrade Upgrades the Telit radio firmware upgrade file
upload config Uploads and sets new configurations configuration file
upload icon Uploads and sets new icon icon file
upload image Uploads and sets new image image file
upload logo Uploads and sets new logo logo file
12 Multi-Tech Systems, Inc. MultiConnect
R
rCell API Developer Guide
Loading...
+ 25 hidden pages