! This post is also available in the following language. Japanese

The Technical Side of LINE Business Connect

My name is Yoichiro, and I work in the Technology Strategy Department here at LINE. We really appreciate everyone out there reading this blog. In today’s post, we’ll be talking about all the juicy details of the technical side of LINE Business Connect, a new service released recently.

About LINE Business Connect

First, let’s talk about what LINE Business Connect actually is. At the core, this service is an official account that allows you to respond to messages automatically by using a program.

Every official account and LINE@ account up until this point has been sending messages to users by having staff members from the operating company post different kinds of messages to the CMS admin interface provided by LINE.

LINE Business Connect offers a whole new level of interaction. The service allows you to create a program that receives messages from users and then replies to them automatically based on the content of the messages themselves.

In other words, LINE Business Connect is a new interactive kind of official account.

Rather than trying to explain it using vague and fuzzy phrases, it’s probably much easier to understand if we take a look at real-life examples. In fact, there have been interactive official accounts on LINE before. Can you guess which ones? Bingo! The automatic translator accounts. These accounts automatically translate received user messages, returning the same message in the target language. It’s pretty obvious that this isn’t done by hand, isn’t it? That’s right, a program automatically handles the series of processes from receiving the message sent by the user to translating and returning the translated message. There are so many different types of messages sent by users that no two messages are exactly alike. In other words, the translated responses are truly diverse, making the automatic translator accounts excellent examples of interactive accounts.

What You Can Do with LINE Business Connect

It would be truly unfortunate if people saw LINE Business Connect simply as a chat bot or service that allows companies to send spam messages. LINE Business Connect is a system that carries with it great potential extending beyond such rudimentary uses. Of course, on a very basic level what the service does is to receive messages from users and return responses, but LINE Business Connect is also capable of changing the daily lives of LINE users.


As the name states, LINE Business Connect is a service that connects businesses with users. The service is not aimed at connecting LINE Corp. with other business, but intended to connect both online and offline businesses with users. Let’s take a look at a pizza company as one representative case of how the service works.

  • A user friends the official account of a certain pizza company.
  • The same user sends a “pizza sticker.”

The above is a very brief summary of the service, but this is basically how it works. Let’s now see how LINE Business Connect would serve a video rental store.

  • A user friends the official account of a certain rental video store.
  • The same user visits the actual store and rents a video.
  • The day before the video’s return date, the user receives a message stating “Don’t forget to return your video tomorrow!”
  • The user goes back to the store to return the video.

How about a taxi business for an even more amazing example?

  • A user friends the official account of a certain taxi business.
  • That same user sends out their current location at a certain intersection.
  • A taxi comes to pick them up a few minutes later.

These might look like extreme examples but in reality none of them are. The key point is that the entire service does not begin and end online, but allows LINE to be used in connection with real-life services. LINE Business Connect is capable of being used to provide a wide variety of services all with the feel of having a conversation with a friend.

Certain people might stretch their interpretations of the second reminder message, thinking that it allows them to repetitively send direct messages to users. However, since this service only allows businesses to send messages to users who have friended them, if businesses choose to send such annoying messages, they will probably get blocked or deleted by the users. This would only result in the business losing users and creating a poor impression that isn’t easily repaired.

The Structure of LINE Business Connect

Now that we’ve gotten an overall grasp of what you can do with the service, let’s go into more technical details.

Before the creation of LINE Business Connect, LINE messages simply went back and forth between the LINE client app and LINE’s servers. Messages sent from the device of a certain user travel through LINE’s servers and arrive at the device of another user. Every message contains within it information on the source and destination of the message. In other words, LINE’s servers perform the duty of delivering messages between users.


The scope of this “delivery” service was expanded on with the release of LINE Business Connect. Until now, there were only two active agents, the LINE client app on the user’s device and LINE’s servers, but with the appearance of LINE Business Connect, the servers of each participating company can now become new active agents in the process. Let’s refer to these servers as “Business Connect servers” for the purposes of this blog entry. With the addition of the Business Connect service, LINE’s servers have taken on the new role of delivering messages to and from Business Connect servers.


In reality, servers collectively called a “Channel Gateway” connect other companies’ services with LINE and handle connections back and forth between the Business Connect servers.

There are two overall categories of data sent and received between the LINE Platform and Business Connect’s servers.

  • Messages: The actual text, sticker, location, and other data sent and received.
  • Operations: Data related to events, such as “added friend” and others.

Of course, the above data is also sent and received between the LINE client app and LINE’s servers. In other words, data that was once only handled within the world of LINE will now be delivered to a variety of services operating all over the world.

Generally speaking, there is no difference between the data sent and received between the LINE client app and LINE’s servers, and the data sent between LINE’s servers (+ Channel Gateway) and the Business Connect servers. Strictly speaking, data necessary for sending information between LINE and other companies’ systems is also added, but essentially the above two sets of data are the same. For those engineers who will be building the Business Connect servers, this might feel like peaking in to the inner workings of LINE itself.

Delivering Information from the LINE Platform to the Business Connect Servers

When users send friend requests or messages to official accounts established under the LINE Business Connect service, the LINE Platform will deliver this information to the Business Connect servers. This will be sent as a Message or Operation written in JSON format to an Endpoint registered in advance on LINE Developers, a website designed for developers. To be even more direct, requests in the request body that contain the JSON lines of text, which in turn contain the information, are sent to the Endpoint URL.

Of course, it would be a big problem if delivered messages could be snooped on, so HTTPS is an absolute requirement. In addition, if the existence of the Endpoint URL is found out by a third party, then there is the potential for unexpected issues to occur if this third party sends fake requests. In order to be able to identify fake requests, the request sent from the Channel Gateway to the Business Connect servers are given unique signatures. The Business Connect servers then calculate the signatures for received requests separately and determine whether this calculated signature matches the signature received in order to check whether the message is fake or not.


You might want to shorten the signature verification process in order to cut down on processing time, but the damage incurred to an official account after an incident can be huge depending on the function provided, and so it is best not to try any short cuts.

As stated earlier, information is sent in the JSON format. There can be multiple messages and operations sent in one request. The number of requests increases or decreases depending on the amount of delivered information and the load experienced by the entire LINE Platform. Concretely speaking you can expect to see the following types of JSON text lines. The number of simultaneous requests sent from the Channel Gateway to the Business Connect servers will also change depending on the amount of delivered information and load.

  "result": [
      "from": "Sender ID",
      "content": {
        "text": "Message body text",
    { Operation 1 },
    { Message 2 },

The main responsibility of Business Connect’s servers is to accept received content and promptly respond with 200. The servers cannot send responses to users who’ve sent messages as responses to requests sent to this Endpoint. Response requests are initiated using the API provided by the Channel Gateway. You should not write code that responds with 200 after that API access is initiated within the process of thread containing this request. Conducting asynchronous processes is required as a condition of the scaling Business Connect servers.

One key is deciding how to code the Business Server in terms of where to store received information. For example:

  • Prepare memory storages like memcached and Redis are and store information on them temporarily.
  • Code information into RDBMS like MySQL. As a lot of inserts will be created under this option, bulk inserts and other tactics can be used to speed up processing as much as possible. You might employ a Handler Socket, etc., if you want even more speed.
  • Utilize some form of a Key-Value store that is cheaper to code in comparison to RDBMS.
  • Place them in a Message queue like Rabbit MQ.

What’s essential is figuring out how to make the storage process lighter in order to have the 200 response returned as quickly as possible.

Information stored on some form of storage is then processed as necessary for the information extracted for use in other processes and threads. You should be able to register as an MQ consumer and process push notifications one after another as needed. It might also be a good idea to have a flow in which multiple Daemon programs obtain and process information from the storage, after which they encode the results.

In terms of encoding the part that processes message deliveries from the LINE Platform, the load distribution strategy employed in the back-end servers of many social games would work well. The know-how once possessed only by a few companies operating certain online portal sites a few years ago has now expanded to many different developing companies. A developer with this sort of experience should be able to construct efficient Business Connect servers.

Delivering Information from the Business Connect Server to the LINE Platform

When you want to send some message in response to a user, you can access the RESTful API provided by the Channel Gateway from the Business Connect servers. There is nothing special about the process, and all you have to do is utilize the RESTful API as you normally would. Of course, a third party cannot be allowed to use the API, so the information required to authenticate the client is set in the request header. Concretely speaking, you will designate the access token that can be obtained from the LINE Developers website. Like the example shows, message contents are designated as JSON lines of text.

POST /api/… HTTP/1.1

Access token header


They key here is to realize that the access token will become invalid after a certain amount of time. Recently, many developers use specs like OAuth2, so this should provide a certain amount of immunity with regards to access tokens becoming invalid. In other words, it is necessary to create a process that automatically reissues a new access token before the previous one becomes invalid. This is different than the typical OAuth2-like access tokens issued to each user as the Business Connect servers as a whole will have their own access token, and so it is best to create a process using cron, etc., to refresh at regular intervals.

Coding Example

In response to the question of what actually happens to code on Business Connect’s servers, let’s take a look at the following case.

class BusinessConnectServerController < ApplicationController
  def index
    # Check signature
    from = params['result'][0]['content']['from']
    msg = params['result'][0]['content']['text']
    BusinessConnectServerController.delay.send_msg(from, msg)
    head 200
  def send_msg(from, msg)
    json = {to:[from], toChannel:…, eventType:…,
        content: {contentType: 1, toType: 1,
        text: "Echo: #{message}"}}
    header = {…} # Set access token header
    url = URI.parse('http://…/v1/events')
    Net::HTTP.start(url.host, url.port) do |http|
      body = json.to_json
      response = http.post(url.path, body, header)

This is an example of code someone wrote as a Ruby on Rails Controller for the Business Connect servers. The code works as an “echo server” in that it tells the servers to accept text messages sent from users and to return the same message to the sender. The code extracts the contents and sender ID of the text message appearing on the first JSON line of text from within the above BusinessConnectServerController index, and then calls up the send_msg function. A delay function appears between these two that sends a command to the “Delayed::Job” library in charge of asynchronous processing to start the process running separately under the send_msg function (concretely speaking, the delay function runs the process of writing data to the database within the send_msg function). To summarize, this code un-syncs the response process, immediately returning the HTTP Status Code 200 as a response.

(Note: I simply used Delayed::Job in order to give a brief explanation of the sample code, and this does not mean that our company necessary recommends the use of Delayed::Job.)

In reality, it is necessary to conduct a signature verification where “Check signature” is written in the comments. In addition, the above code only processes one received message, but it is of course actually necessary to process all information received.

Within the send_msg function, a JSON text line containing the message returned to users is created, and the API conducts the process of passing this message along. An access token is set in the request header during this stage.

What is important here is that, while the signature verification process is abbreviated, the amount of code required on Business Connect’s servers is not very high. It goes without saying that behind the scenes there will likely be other code that needs to be mounted as part of the process of connecting with the services of each company. However, the process of sending and receiving messages, essential from the perspective of LINE Business Connect, is quite simple, as shown above. The more simple the process, the more likely things are to scale.

All that’s left is to focus on what kind of value to provide users with.


In this entry, I introduced you to the LINE Business Connect service with a focus on the delivery of messages. The content of this post covers the essential components of the LINE Business Connect service. In order to actually participate in this service, it will likely be necessary not only to handle the delivery of messages but also operations-related processes, such as automated messages sent when added as a friend, when adding functions aimed at connecting LINE user accounts with the services of each company, and more. I truly hope that this blog entry has helped readers gain a deeper understanding of the LINE Business Connect service.