Tangoe Mobile REST API

ABOUT TANGOE MOBILE REST API

The Tangoe Mobile Platform is a proprietary system built from the ground up. Clients can use any ITSM or originating system to connect with the Mobile REST API as long as it can send structured data to an API and accept structured data via an API. The API is a RESTful interface, allowing Tangoe clients to connect to their mobility data, including ordering and change management, inventory, and support.

Our APIs provide many endpoints that will cover just about any resource for your mobility needs. JSON is the preferred body and payload. We do offer a simplistic approach using a simple link-out option where the user can click on the preferred link such as Device Upgrade and will automatically be linked into the Tangoe Portal through SSO to that particular Activity page. No APIs are used with this option there for the implementation time is all lot quicker.

The more integrated approach is using our APIs so the client can build out forms that live in their ITSM to leverage their data from Tangoe to perform Activity requests, Support, or Inventory. The client should have the resources and understanding of APIs should they choose this option. This will determine how quickly they can implement the build-out option. Both options are discussed under Ways to Connect.

WHAT IS NEEDED TO BEGIN

Before any work begins with the Mobile Integrations Team, certain criteria should be met to help facilitate a smooth transition on both sides.

Tangoe:

1. API Integrations Addendum to the Statement of Work (SOW) needs to be discussed and given to the client.
2. An initial client meeting with the Tangoe team to understand the integration needs so Tangoe can better assist the client in how to leverage the REST API. Ideally, a flow document should be supplied by the client for the specific business processes they would like to accomplish through the integration.
3. In order for a client to most effectively leverage the REST API, the client's asset catalog, users, inventory, and configuration data need to be completed in the Tangoe production portal.
4. Once the client's configuration data is in production, Tangoe will request a data refresh in our lower-level environment (stage) for them to begin testing against the client's specific data. For planning purposes, the refresh process can take up to 2 weeks.
5. Once data is refreshed in stage, Tangoe will provide credentials for the client's stage/testing environment. This includes the endpoint URL and API-Token that will allow the client to begin development against the production-copied data.
6. Concurrently, Tangoe will set up a reverse data communication (Tangoe to Client system). This is the reverse buildout in the case where Tangoe is sending data back to the client's system. Tangoe would in return need credentials and an API endpoint exposed within the client's system in order to build out a workflow to close tickets in the client system. If the client doesn't want Tangoe to send data into their system, the client has the option to use the Tangoe API to PULL data back into their system.

Client:

1. Review our API documents to better understand what we offer and how to leverage the REST API.
2. Create a process flow that captures what you the Client are wanting to accomplish with this integration. This will help facilitate the technical calls by allowing our teams to better understand where the integration points are.
3. Prepare a mapping document to capture the data that is needed within the client system.
4. Setup data communication (Client to Tangoe) with provided credentials from Tangoe.
5. Develop required interfaces, workflows, and processes to allow client users to submit tickets and capture required data needed to send to Tangoe API.
6. If Tangoe is sending data to close tickets on the client-side, the client will need to expose an API endpoint URL along with credentials. These values should be sent back to the Tangoe implementation team.
7. Provide Tangoe example JSON data payloads and data mapping for the client system. This should include API documentation for the client system.

HELPFUL LINKS

WAYS TO CONNECT

AUTHENTICATION

ACTIVITY REQUIREMENTS ( Procurement and Change Management )

DYNAMIC FORM BUILD OUT ( Procurement and Change Management )

CUSTOM FIELD ATTRIBUTE ( Custom Attributes for Activity Payloads )

INVENTORY ( Asset Management )

• Devices/Business_Devices
• Lines/Business_Lines

SUPPORT REQUEST ( Incident Management )

• Support Request ( post )
• Interactions ( post )
• Support Types ( get )

UPDATES TO CLIENT SYSTEM

STATE DEFINITIONS

SUMMARY ( All Endpoints )