">mixi Developer Center (mDC)

mixi Apps

mixi Apps (English) » Technical Specification » PC » Lifecycle Events

Lifecycle Events

“Lifecycle events” are described in OpenSocial 0.8.1. It is described as “The gadget specification allows developers to specify URLs that the container will POST event data to when certain events are triggered”. In mixi Platform specification, following two APIs are currently available:

  • event.addapp
  • event.removeapp

A developer is able to receive the following information on an external server by writing in the Gadget XML in order to retrieve the lifecycle events.

  • who has installed an App
  • who has uninstalled the App

It is useful to use this lifecycle event APIs to handle uninstalled user information or to understand usage status of developing or launching Apps.

How to Use

In order to utilize the lifecycle events for a mixi App, following codes should be described in the Gadget XML file.

  <ModulePrefs ...>
    <Link rel="event.addapp" href="http://example.com/add" method="GET" />
    <Link rel="event.removeapp" href="http://example.com/remove" method="POST" />

Link tag which has following attributes is written as child node of ModulePrefs:

Attributes Descriptions
rel events (event.addapp or event.removeapp)
href URL of an endpoint where a notification is sent
Method http request (GET or POST)

The sample code above is written for

  • a notification that a user has installed a mixi App is sent to http://example.com/add by GET request.
  • a notification that a user has uninstalled a mixi App is sent to http://example.com/remove by POST request.

After adding, modifying or dropping Link tag in the Gadget XML file, a develop press “Change the setting” in edit.appli.pl. Then, Link tags are interpreted and lifecycle events are set up according to the setting written in the Gadget XML file.

note: mixi doesn’t support to specify only “event” for rel attribute. It should be either event.addapp or event.removeapp.


When a notification regarding the lifecycle event is sent, relevant data is also sent as a parameter. Following parameter is sent for each event.


In designating event.addapp for rel attribute, the following parameters are passed:

  • eventtype : “event.addapp”
  • opensocial_app_id : ID for a mixi App
  • id : ID for a user who has installed an App
  • mixi_invite_from : ID for user A who invites user B who has just installed an App

note: when a mixi App is under the development, mixi_invite_from parameter is not sent.


In designating event.removeapp for rel attribute, the following parameters are passed:

  • eventtype : “event.removeapp”
  • opensocial_app_id : ID for a mixi App
  • id : ID for a user who has uninstalled an App

Frequency of the notification

Considering the resources required for a notification of the lifecycle event to the endpoint, it is updated periodically rather than processed dynamically on the real time basis. Therefore, there is a time lag between user’s action and notification.

Besides, in terms of each notification to the endpoint, notification can be re-sent at the following timing to the endpoint in the case that mixi receives any response other than “http status code 200 or 404”. The developer should configure the setting of the endpoint to send 200 as a status code when the request has been successfully received.

Merger of each Event

As described above, the notification is sent periodically. For a certain period of time, same events will be merged as a request. Specifically, assuming there is an app called X, user A, B and C installed the app and the notification is made via GET method to http://example.com/add.

In lieu of sending each request GET /add?opensocial_app_id=X&id=A, GET /add?opensocial_app_id=X&id=B and GET /add?opensocial_app_id=X&id=C, a single request GET /add?opensocial_app_id=X&id=A&id=B&id=C is made.

The developer has to make sure if the endpoint can deal with the request with multiple id parameters.

In addition, if a user installs an app with an invitation, a request has 0 or 1 mixi_invite_from parameter.
Assuming that user B and C install a app with invitations from user A, user D installs the app with the invitation from user B and without any invitation user A installs the app, three independent requests, id=B&id=C&mixi_invite_from=A, id=D&mixi_invite_from=B, and id=A are sent.

Signature Verification

A signature is added in the authorization request header for a request sent by the lifecycle event. By verifying the request, the developer can validate the request.

Signature method is same as a request for gadgets.io.makeRequest(). The following document is available for more detail:


Nevertheless, the request sent by the lifecycle event does not have opensocial_owner_id parameter or opensocial_viewer_id parameter. In addition to verify the signature, the developer has to make sure that the request doesn’t contain these parameters.

Public Key