Server to Server In-App Events API (HTTP API)

Introduction

The purpose of this API is to allow you to send events which occur outside the mobile app, directly to the AppsFlyer server.  For example, if you have both a web and mobile interface, you can record all events from both mediums in AppsFlyer.

Timing the events

You can send the server to server events in real time or in batch mode.

In batch mode, for events to be recorded with their real time stamps, they must all be sent to AppsFlyer by 02:00 AM (UTC) of the following day.   

Events with past time stamps, which are not sent by 2:00 AM, are recorded under the time that they were sent.

Example 1

Event Triggered: 2 May @ 22:00

Event Sent to AppsFlyer's servers: 3 May @ 01:00

Event is recorded in AppsFlyer's platform under the real time that the event occurred (2 May @ 22:00).

Example 2
Event Triggered: 2 May @ 22:00

Event Sent to AppsFlyer's servers: 4 May @ 09:00

Event is recorded in AppsFlyer's platform at the time it was sent to the AppsFlyer server and not the time that the event occurred (4 May @ 09:00).

 Note

The Content Type must be set as application/json.

URL: https://api2.appsflyer.com/inappevent/{app_id}  

Android example: https://api2.appsflyer.com/inappevent/com.appsflyer.myapp

iOS examplehttps://api2.appsflyer.com/inappevent/id123456789

It is important to pay extra attention that the App ID on iOS contains the leading "id" before the ID, otherwise the request ends with HTTPS 200 OK, but the event is not registered.

Method: POST

Header - "authentication"= {dev-key}

The dev key is found in Dashboard >> Settings >> Integrate the SDK

iOS Android
{
"appsflyer_id": {This is a mandatory field, AppsFlyer Device ID must be used },  // i.e. 1415211453000-6513894
"idfa":{idfa},
"bundle_id":{bundle_id},
"eventName": { Event Name as appears in the SDK}, // i.e "af_purchase"
"eventValue": { A JSON containing a rich in-app event value}, // i.e "{\"af_revenue\":\"6\" ,\"af_content_type\":\"wallets\", \"af_content_id\":\"15854\"}"
"eventCurrency": {Event currency}, // i.e "USD"
"ip": {device IP},
"eventTime": {Event timestamp in UTC}, // i.e  "2014-05-15 12:17:00.000"
"af_events_api" :"true"
}

 Note

All Reserved Character (https://tools.ietf.org/html/rfc3986#section-2.1) must be percent-encoded before the URI is formed.

Requirements

  1. eventName, eventValueappsflyer_id (AppsFlyer Device id), idfa, advertising_id and af_events_api are all required parameters
  2. eventValue can be empty:

    e.g. "eventValue": “”, (no space is needed)
  3. eventTime format is as follows and must be reported in UTC timezone:

    "yyyy-MM-dd HH:mm:ss.SSS" (e.g. "2014-05-15 12:17:00.000")  

    * The event time is optional.  If it is not sent, the system uses the timestamp from the HTTPS message received.
  4. IP address should be the IP of the mobile device.

Fetching the appsflyer_id (AppsFlyer Device ID)

1.  From the mobile device. Refer to the section that describes <Get AppsFlyer Unique ID> from the AppsFlyer SDK integration guide (click on link for more information about the SDK for iOS or Android)

2.  Via the Pull or Push API (click on link for more information about Push API or Pull API)

Service Return Codes

200
ok when the request has been processed by the Appsflyer system.
401
unauthorized when the key provided in the authentication header is not the dev-key for this app.
400
Bad request when the request failed at least one of the validation criteria
500
Internal server error this indicates a server error

Request Body Example

{
"appsflyer_id": "1415211453000-6513894",
"advertising_id": "38412345-8cf0-aa78-b23e-10b96e40000d",
"eventName": "af_purchase",
"eventValue": "{\"af_revenue\":\"6\",\"af_content_type\":\"wallets\",
\"af_content_id\":\"15854\",\"af_quantity\":1},
"eventCurrency": "USD",
"ip": "1.2.3.4",
"eventTime": "2014-05-15 12:17:00.000",
"af_events_api" :"true"
}

In this case, AppsFlyer receives an S2S in-app event which represents a purchase event with revenue, as well as additional properties such as content type etc.

AppsFlyer is then able, according to the advertiser's configuration, to send such rich in-app events to media sources for advanced targeting, optimisation and audience creation purposes.

Was this article helpful?
3 out of 7 found this helpful