Deeplink: From URI, to The Depth of an App

1 min read

In the mobile app world, push notification is rapidly gaining prominence as the easiest way for users to receive any kind of information related to the app. After the user tap an incoming notification, the user is being redirected into the relevant page inside the app. Problem is, how could the app know which page that it should open? What information can the notification contain? Here’s several approach to tackle this problem:

Push Notification Payload

For the first release of our Bukalapak app, we put the deeplink information as a custom JSON template. We put all contexts that the app need as an additional payload to the push notification. Here is the example JSON payload for our notification.

               "name":"Xiaobao bluemi 3s"

Not the most elegant or practical format, huh? This format served us well for quite some time. However, we encountered several problems when using this format:

  • Hard to extend. With every new link, we need to modify both our backend API and the mobile app.
  • Big JSON payload. The payload is verbose because we need the payload to complete the partial content template that we store at our mobile app.
  • More expensive to maintain. We need a minimum of two separate user stories every time we want to have a new link.

Deeplink Solution

We translate link with format directly into a specific page in the app. We got this inspiration from deeplinking. Why didn’t we just use the general deeplinking format? Because we want robustness and backward compatibility. In case the app cannot properly redirect the page, maybe because it’s a newer type of page that the older version of the app do not support yet, we want the app to redirect user to the browser.

  "contents": {
    "id": "Transaksi #123123 perlu aksi ini!"
  "headings": {
    "id": "Transaksi Baru!"
  "url": "https:\/\/\/payment\/transactions\/123123",
  "data": {
    "type": "transaction",
    "data_lain": "lain-lain"

Much neater, isn’t it? The data key is used for internal logging and the rest of the information are the mandatory fields that will displayed within the notification. The advantages are:

  • Robust and Generic. With every new type of links, only the app need to be updated. If the link is not yet supported, we can fall back into redirecting users to the browser.
  • Less payload. Front-end app should be as dumb as possible. Receive and display.
  • Easier to maintain. Only one user story per new link is needed.
  • Multi-language support. In case we expand to other markets. 😉

Migration Plan

Of course, as part of the mobile app commandment, we will support both the old version and the new version until the old app user is very low, or if we found special cases that makes us push the force update button.

We have tried the new format for several weeks and we are happy with the result. We will share more about our design decisions on how we built Bukalapak to be the ultimate e-commerce marketplace in Indonesia. Stay tuned!

How Kubernetes can make life easier for Bukalapak’s …

Currently, Bukalapak is transitioning from an monolithic architecture into a microservice-based architecture for its entire software system. This is a massive undertaking that encompass splitting...
Geeas Prisila
1 min read

How I Design My Code

P.S: This post is also available at Medium Programming is becoming mainstream nowadays. I saw people code and build some applications. As a programmer,...
Indra Saputra
1 min read

Leave a Reply

Your email address will not be published. Required fields are marked *