JSON API Tutorial

Introduction

With Unified Messaging, we also upgraded our available JSON APIs - integrating Userlike into your own platforms and workflows has never been easier. Below you find the general documentation as well as a detailed description of each API resource available.

We prepared some cURL-based examples. With the help of the cURL tool you can test drive our API quickly from the command line. This should give you a straightforward understanding how to use our API.

TopicDescription
Resource endpointsAvailable resource endpoints of the JSON API
AuthenticationAccessing the API
Request headersAdditional Request Headers
Rate limitsAPI rate limits
Result paginationNumber of results per requests to the list endpoint of a resource
Result filteringFilter list endpoints for specific resource items
Searching resourcesSearch list endpoints for specific resource items
Conversation resourceWork with conversation resources
Contact resourceWork with contact resources
Operator resourceWork with operator resources
Code samplesWorking (python) code examples

Resource endpoints

Currently, the following resource endpoints are available using the Userlike JSON API:

Resource endpointsDescriptionAllowed methods
https://api.userlike.com/api/um/conversations/
https://api.userlike.com/api/um/conversations/{id}/
List of conversations

Single conversation
GET | DELETE

GET | DELETE
https://api.userlike.com/api/um/contact_identities/
https://api.userlike.com/api/um/contact_identities/{id}/
List of contacts

Single contact
GET | DELETE

GET | PATCH | DELETE
https://api.userlike.com/api/um/operators/
https://api.userlike.com/api/um/operators/{id}/
https://api.userlike.com/api/um/operators/{id}/slots/
List of operators

Single operator

Single operator’s slot data
GET

GET | PATCH | DELETE

GET | PATCH | DELETE

The specifics for each resource are described further below, after the introduction of the general features of the JSON API.

API versioning

Currently we only offer one version of our JSON API: /v1/

You can access all endpoints as described above, without version scheme, or by using the version explicitly in the URLs like this:

https://api.userlike.com/api/um/v1/conversations/
https://api.userlike.com/api/um/v1/conversations/{id}/
https://api.userlike.com/api/um/v1/contact_identities/
https://api.userlike.com/api/um/v1/contact_identities/{id}/
https://api.userlike.com/api/um/v1/operators/
https://api.userlike.com/api/um/v1/operators/{id}/
https://api.userlike.com/api/um/v1/operators/{id}/slots/

Future new versions will be described here and follow the naming scheme "v{integer}", for example: /v2/. Endpoint URLs without version scheme will always default to the **latest** version.

Authentication

All API requests must be authenticated with an API token, i.e. the API token must be passed as an authorization header with each request:

Userlike offers two types of authentication tokens: the "customer authentication token", allowing access to the resources of all organizations, and the "organization authentication token", allowing access to the resouces of a single organization.

organization authentication token

The organization authentication token gives you access to the resources (conversations, contacts, ...) of a single organization. You can find it in your Dashboard under **Config > API settings**:

Customer authentication token

The customer authentication token by default gives you access to the resources (conversations, contacts, ...) of your default organization. You can find it in your Dashboard under **Company > API settings**:

But when you need to access the resources of a different organization, you can now simply provide the extra header "Userlike-organization-Id" with your request, there indicating the ID of the desired organization:

To find the ID of one of your organizations, go to **Company > Organizations** and start editing the respective organization. In the URL bar you can now see the ID of the organization:

If you provide a wrong organization ID, the request will again be made against your default organization resources.

Additional request headers

Content-Type: required for PATCH requests

When you want to update existing resources, you have to send a PATCH request with a valid JSON body. Additionally, you must specify the content type of your request being "application/json" - otherwise your body data cannot be processed correctly.

USERLIKE-OPERATOR-ID: switching operator context

By default, API requests run in the context of the account’s operator. If you want to limit the privileges of requests made via the JSON API without affecting the capabilities of the owner, you can make your requests in the context of a less privileged operator.

In these cases we’d recommend the creation of a dedicated API operator, to whom you then assign a (customized) role with the desired set of capabilities. For all API request you can now send this operator’s ID by setting the custom "Userlike-Operator-Id" header:

All requests made this way will check for your API operator’s capabilities before performing any actions. This way you could ensure, for example, that no destructive operations are allowed via the API. Here you learn more about roles and capabilities.

API rate limits

You can make up to 1000 API requests per day to a specific resource of an organization. After the resource limit is reached, you’ll receive a response with HTTP status code 429.

Each resource has its own limit, as does each organization. This means that requesting conversations of organization A does not affect the count for requesting contacts from the same organization - nor does it affect the count for requesting conversations of organization B. The following three example calls all add to a different call counter:

In this context, requests for a specific resource of an organization (e.g. conversations) all add to the same count, no matter if they are made to the list or single endpoint, or what HTTP method is used. So a "DELETE" of a single conversation adds a hit to the same counter as does a "GET" to the same organization’s conversation list endpoint. The following three example calls all add to the same call counter:

Resource (per organization)Methodscombined requests/day
https://api.userlike.com/api/um/conversations/
https://api.userlike.com/api/um/conversations/{id}/
GET | DELETE

GET | PATCH | DELETE
1000
https://api.userlike.com/api/um/contact_identities/
https://api.userlike.com/api/um/contact_identities/{id}/
GET | DELETE

GET | PATCH | DELETE
1000
https://api.userlike.com/api/um/operators/
https://api.userlike.com/api/um/operators/{id}/
https://api.userlike.com/api/um/operators/{id}/slots/
GET | DELETE

GET | PATCH | DELETE

GET | PATCH | DELETE
1000

Filtering

You can filter the results of each resource’s list endpoint. These filters are specific to each resource, so we’ll explain them for each resource further below. Here we’ll only highlight some details that apply to filters in general.

Ordering filter

By default, the list of resources returned by all list endpoints are sorted by their ID, in descending order - meaning that the most recently created resources are coming first.

For some resource list endpoints, you can provide an alternative ordering by providing the field by which the result list should be ordered. Prefixing the ordering field with a "-" (minus) sign will reverse the order from "ascending" to "descending":

For each resource list endpoint we’ll indicate which fields are available for alternative ordering.

Filters and pagination

Applying filters to an API requests means that the pagination is applied to the filtered result set, and the previous and next links provided in a filtered response will already have these filter set. This means that you can easily browse the single pages of a filtered result set by following these links.

Combining filters

You can apply more than one filter to an API request. The single filters are "ANDed" together, i.e. they will return all resource items that match each filter criterion.

The more filters you add, the more specific your request will be and chances are that there are no items matching all criteria.

Exclude IDs

For any requests, to any resource endpoints, you can provide a "blacklist" of resource IDs. Just provide a comma-separated string with all IDs you wish to exclude via the "exclude_ids" filter. Resource(s) thus specified will not be fetched, updated or deleted.

This allows for more effective bulk actions, e.g. fetching all conversations that are not assigned to one specific operator with only two API calls:

First you filter all conversation resources for the operator whose conversations you want to exclude, extracting the single conversation IDs from the result list. Then you make another call to the conversation list resource endpoint, providing this list of IDs to be excluded, as comma-separated value:

Delete IDs

For DELETE requests to list endpoints, you can provide a "whitelist" of resource IDs. Just provide a comma-separated string with all IDs you wish to delete via the "delete_ids" filter. Only the resource(s) thus specified will be deleted.

This allows for safer bulk delete actions, since only the specified IDs will be deleted, no matter what other filters or limits are provided:

Searching

Searching is really a special kind of filtering, available for the conversation and contact list endpoints. For each resource, certain fields will be searched and all matching results will be returned, ordered by a specific ranking. We will explain the individual fields and ranking for each resource below.

To search an endpoint for specific resources, simply add the "search_query" parameter to your request, followed by the search keyword:

Multiple keywords

You can search for multiple keywords in one request by providing the "search_query" parameter with a white-space separated value. Since you cannot use literal whitespaces in your request URLs, use one of the following encodings:

EncodingValueExample
"Percent" encoding%20?search_query=userlike%20gregor
"Plus" encoding+?search_query=userlike+gregor

Multiple keywords are "ORed", meaning that a search for "userlike+gregor" will return results that match either the first or the second keyword:

Ranking

The ranking of all results matching your keyword(s) is determined by two factors: where the matching content was found and how often it was found. A match in a contact’s name ranks higher than a match in a contact’s notes, and three matches in one conversation rank higher than only one match in another.

Ranking factorExampleDescription
WeightAThe ranking prominence follows the natural order of the letters, i.e. "A" ranks higher than "B" ranks higher than "C"
Occurrence3The more occurences, the higher the ranking

The ranking of each resource’s search fields are described below.

Stemming and Prefix Search

When you provide a keyword, it is first reduced to its stem. After that we do a prefix search with the result. E.g. if you enter "users", we first reduce it to the word stem "user" and then do a prefix search with that. So it would return results for e.g. "userlike". Multiple keywords are all treated as prefixes as well:

Provided search keyword(s)Actual search
?search_query=useruser*Matches "user", but also e.g. "userlike"
?search_query=user+greguser* || greg*Matches e.g. "user", "userlike", "greg" or "gregor"

Keep this in mind if your search returns too many (undesired) results, and provide more specific search keyword(s).

Conversation resource

Resource endpointsDescriptionAllowed methods
https://api.userlike.com/api/um/conversations/
https://api.userlike.com/api/um/conversations/{id}/
List of conversations

Single conversation
GET | DELETE

GET | DELETE
Conversation list endpoint - GET

Fetch a list of conversations you had with your contacts. The resposne will return a JSON object with a results array, by default containing the last 10 conversations that were created. The response JSON further contains pagination details.

The conversation resource items returned by the list endpoint only contain the last message of the conversation. If you want to get the full conversation data, you must make a request to the conversation single endpoint, which we show how to do further below.

Conversation list endpoint - DELETE

Delete a list of conversations you had with your contacts. The response contains no data and has the HTTP status 204.

Making a DELETE request to the conversation list endpoint will irrevocably delete a number of conversations at once: 10 by default and 100 at most. As a precaution, you cannot delete ongoing conversations.
Conversation list endpoint filters

The conversation list endpoint lets you filter its resources for the following fields:

FieldSample valueDescription
contact_uuidMGEwYWJmZmEtN2M1OS01NGI2LWE2OWYtZWYxNDY4OWM0YWQ3Get all conversations you had with a specific contact
operator_id23Get all conversations of a specific operator by their ID
statuspendingGet all conversations you assigned a certain status
topicsSupportGet all conversations you assigned a certain topic label to
um_widget_id42Get all conversations that were hold (at least partially) via a specific Widget.
to_date2018-11-07Get all conversations that were updated before a specific date
from_date2018-11-05Get all conversations that were updated after a specific date
iso_to_date_time2018-09-22T14:01:54.9571247ZGet all conversations that were updated before a specific time
iso_from_date_time2018-07-22T14:01:54.9571247ZGet all conversations that were updated after a specific time

You can use these filters alone or in combination to extract exactly the resource items you need.

You can also use these filters to immediately delete the filtered resource items.

Making a filtered DELETE request to the conversation list endpoint will also irrevocably bulk delete a number of conversations: 10 by default, 100 being the maximum allowed limit.

Make sure you also read the general remarks on result filtering.

Conversation list endpoint searching

The conversation list endpoint lets you search its resources by matching your search keyword(s) against certain data fields of or related to your conversations. If your keyword(s) match(es) any of the contents of the following fields, the respective conversation will be part of the result set:

FieldRankingDescription
Contact's nameAGet all conversations whose contact’s name matches the keyword
Contact's emailAGet all conversations whose contact’s email matches the keyword
Contact's streetAGet all conversations whose contact’s street name matches the keyword
Contact's cityAGet all conversations whose contact’s city matches the keyword
Conversation messagesCGet all conversations whose messages matches the keyword

We intentionally rank matches in the associated contacts' data higher than matches in the conversations' own content, since that data is much more structured and qualified.

You can also use the search feature to immediately delete the matching conversations:

Making a search DELETE request to the conversation list endpoint will irrevocably bulk delete the matched conversations: 10 by default, 100 being the maximum allowed limit.

Make sure you also read the general remarks on resource searching.

Conversation list endpoint ordering

The conversation list endpoint results can be alternatively ordered by the following fields:

FieldValueDescription
orderinglast_message_sent_atOrder the conversations according to when the last message was sent, in ascending order (oldest first).
ordering-last_message_sent_atOrder the conversations according to when the last message was sent, in descending order (latest first).
orderingcontact_first_message_sent_atOrder the conversations according to when the first contact message was sent, in ascending order (oldest first).
ordering-contact_first_message_sent_atOrder the conversations according to when the first contact message was sent, in descending order (latest first).
orderingcontact_last_update_atOrder the conversations according to when its contact was last updated, in ascending order (oldest first).
ordering-contact_last_update_atOrder the conversations according to its contact was last updated was sent, in descending order (latest first).

Make sure you also read the general remarks on result filtering.

Conversation single endpoint - GET

Fetch a specific conversation you had with one of your contacts by providing its ID. The returned JSON object contains the full conversation, including all its parts.

If you need the full conversation data for a specific set of conversations, first filter the resource items accordingly using the list endpoint. Then use the conversation IDs you get from the filtered result set to fetch the single resource items, which will contain the full data.

The "transcript" key contains a list of messages and events that happened during a conversation. Here is an example of one list entry:

Conversation single endpoint - DELETE

Delete a specific conversation you had with one of your contacts by providing its ID. Response contains no data and has HTTP status 204.

Contact resource

Resource endpointsDescriptionAllowed methods
https://api.userlike.com/api/um/contact_identities/
https://api.userlike.com/api/um/contact_identities/{id}/
List of contacts

Single contact
GET | DELETE

GET | PATCH | DELETE
Contact list endpoint - GET

Fetch a list of contacts. Returns a JSON object with a results array, by default containing the last 10 contacts that have been created. The response JSON further contains pagination details.

Contact list endpoint - DELETE

Delete a list of contacts. The response contains no data and has HTTP status 204.

Making a DELETE request to the contact list endpoint can potentially bulk delete a number of contacts: 10 by default, 100 being the maximum allowed limit.
Contact list endpoint filters

The contact list endpoint lets you filter its resources for the following fields:

FieldSample valueDescription
id23Get the contact matching the given ID
emaildavid@userlike.comGet the contact with the specified email
nameDavid VoswinkelGet all contacts matching a specific name
to_date_time2018-09-22T14:01:54.9571247ZGet all contacts that were active before a specific time
from_date_time2018-07-22T14:01:54.9571247ZGet all contacts that were active after a specific time
verifiedtrueGet all contacts that have a verified email or mobile number
localeen_USGet all contacts that match the given locale

You can use these filters to extract exactly the resource items you need.

You can also use these filters to immediately delete the filtered resource items.

Making a filtered DELETE request to the contact list endpoint can potentially bulk delete a number of contacts: 10 by default, 100 being the maximum allowed limit.

Make sure you also read the general remarks on result filtering.

Contact list endpoint searching

The contact list endpoint lets you search its resources by matching your search keyword(s) against certain data fields of your contacts. If your keyword(s) match(es) any of the contents of the following fields, the respective contact will be part of the result set:

FieldRankingDescription
Contact's nameAGet all conversations whose contact’s name matches the keyword
Contact's emailAGet all conversations whose contact’s email matches the keyword
Contact's streetAGet all conversations whose contact’s street name matches the keyword
Contact's cityAGet all conversations whose contact’s city matches the keyword
Contact's countryAGet all conversations whose contact’s country matches the keyword
Contact's notesBGet all conversations where your notes about the contact matches the keyword

An example contact search:

You can also use the search feature to immediately delete the matching contacts:

Making a search DELETE request to the contact list endpoint will irrevocably bulk delete the matched contacts: 10 by default, 100 being the maximum allowed limit.

Make sure you also read the general remarks on resource searching.

Contact list endpoint ordering

The contact list endpoint results can be alternatively ordered by the following fields:

FieldValueDescription
orderingcreated_atOrder the contacts according to when they were created, in ascending order (oldest first).
ordering-created_atOrder the contacts according to when they were created, in descending order (latest first).
orderingnameOrder the contacts by their names, in ascending order (A-Z).
ordering-nameOrder the contacts by their names, in descending order (Z-A).
orderingemailOrder the contacts by their email, in ascending order (A-Z).
ordering-emailOrder the contacts by their email, in descending order (Z-A).

Make sure you also read the general remarks on result filtering.

Contact single endpoint - GET

Fetch a specific contact by providing its ID. The returned JSON object contains the full contact representation.

Contact single endpoint - PATCH

Update certain data of a specific contact. The returned JSON object contains the full and updated contact.

The following fields can be updated:

FieldSample valueDescription
emailmy.contact@customer.comUpdate the contact’s email address
name"Jane Doe"Update the contact’s name
salutation"mrs"Update how the contact whishes to be saluted
gender"f"Update the contact’s gender
street"Sunset Blvd"Update the contact’s street
city"Cologne"Update the contact’s city
country"DE"Update the contact’s country, providing a valid two-digit iso code.
phone_number"+49521234567"Update the contact’s phone number
mobile_number"+49521234567"Update the contact’s mobile number
contact_by_phoneTrueUpdate if the contact wants to be contacted via phone
contact_by_emailTrueUpdate if the contact wants to be contacted via email
contact_by_userlike_messengerTrueUpdate if the contact wants to be contacted via the Website Messenger
contact_by_userlike_channelsTrueUpdate if the contact wants to be contacted via channels
url_facebook"https://facebook.com/xy"Update the contact’s Facebook URL
url_twitter"https://twitter.com/xy"Update the contact’s Twitter URL
url_linkedin"https://linkedin.com/xy"Update the contact’s Linkedin URL
url_profile_picture"https://url_profile_picture.com/xy"Update the contact’s profile picture URL
external_customer_id"123"Update the contact’s external id

You can update one or more of these fields with a single patch request.

In contrast to a single conversation, you can update nearly all fields of a contact via the API. This allows you to enrich your Userlike contacts with data from another CRM system you might have, for example.

Contact single endpoint - DELETE

Delete a specific contact by providing its ID. Response contains no data and has HTTP status 204.

Operator resource

Resource endpointsDescriptionAllowed methods
https://api.userlike.com/api/um/operators/
https://api.userlike.com/api/um/operators/{id}/
https://api.userlike.com/api/um/operators/{id}/slots/
List of operators

Single operator

Single operator’s slot data
GET

GET | PATCH | DELETE

GET | PATCH | DELETE

In contrast to the other resources, the operator resource’s list endpoint does not offer bulk deletion. This is to prevent destructive API calls that could seriously affect the operation of your Userlike account.

Operator list endpoint - GET

Fetch a list of operators. Returns a JSON object with a results array, by default containing the last 10 operators that have been created, including their current chat slot utilization. The response JSON further contains pagination details.

Operator list endpoint filters

The operator list endpoint lets you filter its resources for the following fields:

FieldSample valueDescription
id23Get the operator matching the given ID
emaildavid@userlike.comGet the operator with the specified email
nameDavid VoswinkelGet all operators matching a specific name
operator_group_id132Get all operators belongig to a specific operator group

You can use these filters to extract exactly the resource items you need.

Make sure you also read the general remarks on result filtering.

Operator list endpoint ordering

The operator list endpoint results can be alternatively ordered by the following fields:

FieldValueDescription
orderingcreated_atOrder the operators according to when they were created, in ascending order (oldest first).
ordering-created_atOrder the operators according to when they were created, in descending order (latest first).
orderingnameOrder the operators by their names, in ascending order (A-Z).
ordering-nameOrder the operators by their names, in descending order (Z-A).
orderingemailOrder the operators by their email, in ascending order (A-Z).
ordering-emailOrder the operators by their email, in descending order (Z-A).

Make sure you also read the general remarks on result filtering.

Operator single endpoint - GET

Fetch a specific operator by providing its ID. The returned JSON object contains the full operator representation, including operator group and organization.

Operator single endpoint - PATCH

Make various changes to a specific operator.

You can use the PATCH method to update an operator’s out of office status or notification settings. The response will have the format of the slot view as described below.

The following fields can be updated:

FieldSample valueDescription
um_notification_message_receivetrueTurn browser notification for new messages on or off
um_notification_chat_session_forwardtrueTurn browser notification for reassigned conversations on or off
um_notification_conversation_ratingtrueTurn browser notification for conversation ratings on or off
um_notification_conversation_feedbacktrueTurn browser notification for conversation feedback on or off
um_notification_conversation_post_surveytrueTurn browser notification for post-conversation surveys on or off
um_notification_conversation_goaltrueTurn browser notification for reached Widget goals on or off
um_notification_conversation_endtrueTurn browser notification for ended conversations on or off
um_notification_conversation_offline_assignedtrueTurn browser notification for assigned offline conversations on or off
um_notification_conversation_livetrueTurn browser notification for incoming live conversations on or off
um_notification_conversation_not_livetrueTurn browser notification for timeout being reached in a conversation on or off
um_notification_conversation_end_owntrueTurn browser notification for own conversation ending on or off
um_notification_conversation_feedback_owntrueTurn browser notification for feedback in own conversations on or off
um_notification_conversation_goal_owntrueTurn browser notification for Widget goals reached in own conversations on or off
um_notification_conversation_offline_unassignedtrueTurn browser notification for unassigned conversations on or off
um_notification_conversation_startedtrueTurn browser notification for conversation started or resumed on or off
um_notification_conversation_post_survey_owntrueTurn browser notification for post-conversation survey answers in own conversations on or off
um_notification_conversation_rating_owntrueTurn browser notification for ratings on own conversations on or off
um_notification_operator_availabilitytrueTurn browser notification for operator status changes on or off
sound_connecttrueTurn sound notification for operator connecting to UMC on or off
sound_disconnecttrueTurn sound notification for operator disconnecting from UMC on or off
sound_message_newtrueTurn sound notification for new message being received in a conversation on or off
sound_operator_offtrueTurn sound notification for operator going offline on or off
sound_operator_ontrueTurn sound notification for operator going online on or off
sound_conversation_livetrueTurn sound notification for received live conversations on or off
sound_conversation_offlinetrueTurn sound notification for received offline conversations on or off
notification_mutetrueMute or unmute all notifications
out_of_officetrueTurn out of office mode on or off

You can update one or more of these fields with a single PATCH request.

Operator single endpoint - change operator status

You can toggle an operator’s availability between **online** and **away** by making a PATCH request. The response contains the operator’s slot data and has the HTTP status code 200.

Operator single endpoint - DELETE

Delete a specific operator by providing its ID. The response contains no data and has HTTP status 204.

Since deleting an operator can affect the operation of your Userlike account, we take some precautions to prevent you from causing serious harm when making a DELETE call.

We make sure that you do not accidentally:

  • Delete the Owner of your Userlike account
  • Delete the operator making the request (which in most cases is the Owner)
  • Delete the last operator of an organization

When you make a call that would cause one of these actions, you’ll instead get a 403 status response, indicating your request was denied. In the JSON body you’ll find the details on why it was denied.

Operator single endpoint - slot view

For single operator resource items, we offer an additional endpoint that only returns the specific operator’s slot data when making a GET request to it. Apart from that, all other requests behave exactly the same as those to the regular operator resource single endpoint.

Use this reduced "view" on a specific operator’s chat slot utilization if all you need is this subset of the operator’s data. For example, when you are using the JSON API to sync your operators' chat availability with an external support system.

The fields of an operator’s slot data are:

FieldDescription
availabilityThe operator’s presence status, combined from the fields "available" and "connected". Its value can be "available", "unavailable" or "offline".
availableWhether the operator is available to chat
connectedWhether the operator is currently connected to the Message Center
freeNumber of free chat slots
usedNumber of used chat slots
totalNumber of the operator’s total chat slots

Python Examples

We prepared a few examples on how to access the Userlike API using Python. It’s pretty straightforward, we use the Python library "requests" for the HTTP requests, always adding the required Authorization headers.

Simple example: fetch last conversations

This very basic example shows you how to retrieve the list of the latest 10 conversations you had with your customers with a small Python script.

More complex example: assign all open conversations to a new operator

This larger example shows you how to work with different endpoints and request types to fulfill a task.

Imagine the following use case: you finally have a new operator on your team and want to assign them all customer conversations that still have the status "open".

For this, you first have to get the ID of the new operator by filtering the operator resource endpoint with their email address. Second, you have to get the list of all conversation (IDs) whose status is "open", by filtering the conversation resource list endpoint. Finally, you have to update these single conversations by assigning the new operator to them, sending patch requests to each individual conversation resource endpoint.