Tangoe Mobile REST API

Mobile incident management or what we refer to as support requests can accommodate different tiers of support. We have two basic ticket types in our system. Call Logs, the record of the live incoming call and support request, a non-live asynchronous support ticket where a user goes into their system and fills out an incident ticket, and it then gets routed to Tangoe to be worked by our Account Specialist.

To begin a two-way communication between systems, Tangoe would provide an endpoint URL and an API Token and in return would need similar credentials. The first API created would be a support request to capture the incident followed by the interaction endpoint where the user would add comments about the support request. On the reverse side, the Tangoe Account Specialist would interact and close the support request.

A process diagram or some mapping to capture how the client will envision each scenario might work will help to get this collaboration started. Tangoe will need to know what information should be sent back upon the closure of the support request.

Essentially, a mobile incident ticket is opened on the client side and is routed to Tangoe based on certain conditions. Tangoe will work the ticket and change the state to one of the states listed below. The state change should reflect on both sides.

States and definitions to represent the current request status:

• Externally Queued - Resolution is pending information from a third-party source.
• Awaiting Customer Response - Tangoe responds to the ticket and is waiting for a response.
• Closed - The request has been resolved and no longer requires attention.
• Canceled - Deletes the request from reports on active requests. No further action is required.

Tangoe is not going to be one-to-one congruent with all the fields in other ticketing systems. For anything that doesn’t map directly from your system to our system, we suggest putting it in the text field.

Support Request Payload Attributes

Example Support Request Body Payload

Note: If you send the employee_id in the support request URL as a query parameter, we can better associate it with a user. Example URL: [https://{subdomain}.thefutureis.mobi/1/support_requests?employee_id=12]

POST:

{
  "support_request": {
  "text": "I broke my phone",
  "requestor_name": "Name Here",
  "requestor_number": "1234567890",
    "request_type": "Portal Assistance",
    "external_source_id": "SN123",
    "device_type": "Smart Phone",
    "vip": "true"
  }
}

Example support request response payload.

{
    "id": 43413,
    "requestor_name": "Insa Dent",
    "requestor_number": "(555) 259-6624",
    "number_request_is_about": "(555) 259-6624",
    "on_behalf_of_id": 1831571,
    "line_id": null,
    "assigned_to_id": 10833529,
    "device_type": "Smart Phone",
    "state": "open",
    "created_at": "2021-03-14T21:43:16.151-04:00",
    "updated_at": "2021-03-14T21:43:16.279-04:00",
    "third_party_source": "ServiceNow",
    "requestor_id": null,
    "external_source_id": null,
    "request_type": "application_support_on_device",
    "interaction_thread": {
        "token": "m339xS26p8ZML2U4RQCJo83H"
    },
    "interactions": [{
        "id": 453453,
        "text": "Can't open email on new device.",
        "created_at": "2021-03-14T21:43:16.272-04:00",
        "person": {
            "id": 1831571,
            "name_last": "Quackers",
            "name_first": "Pinkerton",
            "name_middle": null,
            "group_id": 1605,
            "email": "administrator@sandbox.com",
            "login": "administrator@sandbox.com",
            "employee_id": "10000",
            "created_at": "2014-09-15T16:51:35.404-04:00",
            "updated_at": "2021-03-11T16:20:59.689-05:00",
            "cost_center": "CEO-001",
            "active": true,
            "customer_data": {}
        }
    }],
    "on_behalf_of": {
        "id": 1831571,
        "name_last": "Quackers",
        "name_first": "Pinkerton",
        "name_middle": null,
        "group_id": 1605,
        "email": "administrator@sandbox.com",
        "login": "administrator@sandbox.com",
        "employee_id": "10000",
        "created_at": "2014-09-15T16:51:35.404-04:00",
        "updated_at": "2021-03-11T16:20:59.689-05:00",
        "cost_center": "CEO-001",
        "active": true,
        "customer_data": {},
        "group_name": "Demo Group A"
    },
    "assigned_to": {
        "id": 10833529,
        "name_last": "test",
        "name_first": "test",
        "name_middle": null,
        "group_id": 1955,
        "email": "sandboxmobility@mobiwm.com",
        "login": null,
        "employee_id": null,
        "created_at": "2019-07-10T15:27:03.857-04:00",
        "updated_at": "2020-01-09T10:35:19.534-05:00",
        "cost_center": "",
        "active": true,
        "customer_data": null,
        "group_name": "Pi-oneers"
    },
    "attachments": []
}

Within this response, an interaction thread token is generated. Interactions are essentially work notes or comments in our system. Whenever a new comment is added to a support request, it is added using the interaction endpoint. See Figure 5. This will add comments to the existing ticket.

Example Close Webhook Attributes

Here is a simple example support request closure payload being sent back to the client's system. Other attributes can be sent, depending on what attributes the client needs to update their system.

Closed/Complete Payload

Other Webhooks that Tangoe would send Updates back to the Client

• Cancel (what State needed to cancel)
• Interaction/Note Updates (what State is needed, this usually might fall under work_in_progress)
• Reassign (what State needed) (reassign back to the client, Tangoe would need an assignment group to reassign back to)

Example interaction body payload using the interaction_thread_token captured from the initial support request post.

https://{subdomain}.thefutureis.mobi/1/interactions

POST:

{
  "interaction": {
    "interaction_thread_token": "m339xS26p8ZML2U4RQCJo83H",
    "text": "Interaction text."
  }
}