Implementing OpenGDPR API

At a glance: This article is for the use of AppsFlyer clients, often referred to as advertisers or app owners, using the Platform to record app use and attribution. App owners implement OpenGDPR API to comply with applicable data protection laws like GDPR (Europe), CCPA (California), LGPD (Brazil), and PDPA (Thailand).

A word from our lawyers: Nothing stated here is legal advice. It is provided for your information and convenience. You should work closely with legal and other professional advisors to determine exactly how GDPR, CCPA, or any other laws may or may not apply to you. The privacy relationship between you and AppsFlyer is governed by the AppsFlyer Services Privacy Policy. For any questions relating to this Services Privacy Policy or to contact our data protection officer please send us a mail to For the purposes of Article 27 of the General Data Protection Regulation, the representative within the EU of AppsFlyer is AppsFlyer Germany GmbH Kurfürstendamm 11, c/o WeWork, 10719 Berlin, Germany (contact; +49-30-3119-9129)

Privacy regulations

In this article, references to privacy regulations include the regulations listed in the table that follows.

Regulation Logo Description
GDPR GDPR.png The General Data Protection Regulation is the EU regulation relating to data protection and privacy for European Union citizens
CCPA CCPA.png California Consumer Privacy Act 
LGPD LGPD.png Lei Geral de Proteção de Dados
PDPA 6137_Privacy_Shield_Thailand-01.png Personal Data Protection Act

The terms privacy regulations, GDPR, CCPA, LGPD, and PDPA are used interchangeably in this article. 

The OpenGDPR initiative

To address and manage requests by Data Subjects submitted in accordance with privacy regulations, AppsFlyer, together with mParticle, Amplitude, and Braze, initiated the OpenGDPR protocol.

OpenGDPR is an open-source framework, facilitating cooperation between technology companies for the fair and transparent use of consumer data. It enables vendors to take data privacy actions across multiple systems that process and store customer data.

You can read more about the initiative here.


GDPR Term AppsFlyer Term Description
Data Subject App User or End-user The App User about whom data is collected
Data Controller App Owner or Advertiser The App Owner determines the purpose and means by which the personal data is processed. 
Data Processor AppsFlyer and its partners AppsFlyer and its partners process personal data on behalf of the data controller

GDPR requirements

GDPR details the mandatory rights of the Data Subject, with which the Data Controller must comply. For API purposes these rights are translated into request types. The following details how AppsFlyer processes the different request types. 

Request type


GDPR definition

Processing of the request by AppsFlyer 


  • If requested, App Users have the right to know if, why, and for how long the App owner will process their data.
  • If data is shared with third parties, like AppsFlyer, App Users have the right to know who those third parties are.
  • The right to know what categories of data are being processed.
  • If there is automated processing, that has a significant effect on them.
The App Owners receive a copy of the App Users' processed personal data.


The App User needs to receive all of their personal data in a structured, commonly used, and machine-readable format, such as a CSV file.

The App Owner receives a copy of the App User's processed personal data.


Allows App Users to correct their data if they see it is inaccurate or untruthful. App Owners have to erase or correct inaccurate or incomplete data.

  • AppsFlyer deletes the App User's data recorded prior to the date of the rectification request.
  • Data received thereafter is recorded by AppsFlyer.


The right of erasure forces App Owners to remove personal data within one month of receiving the request.

The data is deleted

AppsFlyer GDPR Requests API

Use the GDPR Requests API as described in this section to implement GDPR compliance. 

  • GDPR Request: Perform one of the above request types: access, portability, erasure, rectification.
  • Status Request: Query the current status of a GDPR request.
  • Discovery Request: Inquire as to the supported API version and Data Format.
  • Cancellation: Cancel a GDPR request during its pending phase.

App Owners must implement UI changes to their app so that App Users can submit requests. Note that GDPR requests are per single user at one time.

1. GDPR request

GDPR request flow

The GDPR request types, access, portability, erasure, and rectification, have the same flow:

  1. App User submits a request.
  2. The App Owner constructs the GDPR request (see below) and sends it to AppsFlyer.
  3. AppsFlyer receives the request and responds with a "201 OK" for valid requests.
  4. During the following 48 hours, the request is queued and has a pending status. The App User may cancel the request. 
  5. After 48 hours, the request status changes to in_progress. AppsFlyer sends a ‘status change’ postback. The request can't be canceled. 
  6. a) Within 28-days AppsFlyer fulfills the request.
    In the case of erasure or rectification, the App User's data is deleted.
    In the case of portability or access, the App User's data can be accessed in the AppsFlyer dashboard under GDPR, or via the Request API (see below).
    b) The request status updates to completed. AppsFlyer sends a status change postback.

GDPR request format

A GDPR Request API can be submitted via HTTP POST to the following endpoint -[api token]

The API token is the same API token used for Pull API. The Admin retrieves the Pull API token from the API token page in the Dashboard.

Property Name Mandatory Description
subject_request_id Yes UUID v4 string. Generated by the controller at the time of request submission to a Processor. It can then be used in order to check the status of the request, update or cancel it.
subject_request_type Yes

String value representing the type of GDPR Request. Supported values:

  • erasure
  • portability
  • access
  • rectification
subject_identities Yes
  • An array of identity objects defining the requester's identity (see below).
  • Each request can contain only one subject identity.
submitted_time Yes
  • RFC 3339 date string of the time of the original request by the data subject
  • Timestamps in UTC
property_id Yes

String representing the mobile app to which this request is scoped:


  • iOS: id123456789 
  • Android: com.example, 
  • Android out-of-store:
    Note In some cases, app owners record out-of-store attribution using the Android Google Play name. In these cases use the regular app name as it displays in the Dashboard.
api_version No Version string representing the desired version of the GDPR Requests API
status_callback_urls Yes
  • An array of endpoints for status callbacks to be sent to the following request status changes.
  • Only HTTPS endpoints are supported.
Subject_identities objects
Object type Mandatory Description
identity_type Yes
  • The identity type in string format:
    • ios_advertising_id
    • android_advertising_id
    • fire_advertising_id
    • microsoft_advertising_id
    • appsflyer_id
  • Example: android_advertising_id
identity_value Yes
  • Format: String
  • Example: "a7551968-d5d6-44b2-9831-815ac9017798"
identity_format Yes
  • The method used to encode the identity_value: raw is the only supported:
  • Example: "raw"

Example GDPR erasure request 

curl --location --request POST '[api_token]' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data-raw '{ 

GDPR erasure request code example

using the okhttp package install from maven

import okhttp3.*;

public class GdprSendRequest {
 public static void main(String[] args){

  OkHttpClient client = new OkHttpClient();
  RequestBody body = RequestBody.create(null, "" +
  "{\r\n\"subject_request_id\": \"<SUBJECT_ID>\"," +
  "\r\n\"subject_request_type\": \"erasure\"," +
  "\r\n\"submitted_time\": \"2018-11-02T15:00:00Z\"," +
  "\r\n\"subject_identities\": [\r\n" +
  "{\r\n\"identity_type\": \"android_advertising_id\"," +
  "\r\n\"identity_value\": \"<ADVERTISING_ID>\"," +
  "\r\n\"identity_format\": \"raw\"\r\n}" +
   "\r\n]," +
   "\r\n\"property_id\": \"com.example.application\"}");

  Request request = new Request.Builder()
  .addHeader("Content-Type", "application/json")
   .addHeader("Accept", "application/json")

  try {
   Response response = client.newCall(request).execute();
  } catch (IOException e) {

2. Status request

Every submitted GDPR request can be later queried for its status, by specifying the subject_request_id. There are four supported status types:

  1. pending - A correct request has been received and is currently in the queue
  2. in_progress - A request is currently being acted on
  3. completed - A request has been fulfilled
  4. canceled - A request has been canceled

Status request format

A status request can be submitted via HTTP GET to the following endpoint:[subject_request_id]?api_token=[api token]

Status response example

HTTP/1.1 200 OK
Content-Type: application/json
X-OpenGDPR-Processor Domain: example

Status postbacks

As described in the GDPR Request Flow above, when the status of a GDPR request changes, from pending to in_progress to completed, AppsFlyer sends a GDPR postback to the requesting endpoints, specified with the status_callback_urls property.

Status Postback Example:

POST /opengdpr_callbacks HTTP/1.1
Content-Type: application/json
X-OpenGDPR-Processor Domain:
X-OpenGDPR-Signature: kiGlog3PdQx+FQmB8wYwFC1fekbJG7Dm9WdqgmXc9uKkFRSM4uPzylLi7j083461xLZ+mUloo3tpsmyIZpt5eMfgo7ejXPh6lqB4ZgCnN6+1b6Q3NoNcn/+11UOrvmDj772wvg6uIAFzsSVSjMQxRs8LAmHqFO4cF2pbuoPuK2diHOixxLj6+t97q0nZM7u3wmgkwF9EHIo3C6G1SI04/odvyY/VdMZgj3H1fLnz+X5rc42/wU4974u3iBrKgUnv0fcB4YB+L6Q3GsMbmYzuAbe0HpVA17ud/bVoyQZAkrW2yoSy1x4Ts6XKba6pLifIHf446Bubsf5r7x1kg6Eo7B8zur666NyWOYrglkOzU4IYO8ifJFRZZXazOgk7ggn9obEd78GBc3kjKKZdwaCrLx7WV5y9TMDCf+2FILOJM/MwTUy1dLZiaFHhGdzld2AjbjK1CfVzyPssch0iQYYtbR49GhumvkYl11S4oDfu0c3t/xUCZWg0hoR3XL3B7NjcrlrQinB1KbyTNZccKR0F4Lk9fDgwTVkrAg152UqPyzXxpdzXjfkDkSEgAevXQwVJWBNf18bMIEgdH2usF/XauQoyrne7rcMIWBISPgtBPj3mhcrwscjGVsxqJva8KCVCKD/4Axmo9DISib5/7A6uczJxQG2Bcrdj++vQqK2succ=

"controller_id":"example controller id at the processor",

3. Report request

Once an Access Request or Portability Request has been completed, you can download the report via HTTP GET to the following endpoint:[REQUEST_ID]?api_token=[TOKEN]

The generated report is available for fourteen days from the time of completion.

4. Discovery request

To learn about the formats supported by AppsFlyer, a discovery request can be submitted via HTTP GET to the following endpoint:[api token]

Discovery response example

HTTP/1.1 200 OK
Content-Type: application/json
 "api_version": "0.1",
 "supported_identities": [
  "identity_type": "android_advertising_id",
  "identity_format": "raw"
 "supported_subject_request_types": [
 "erasure", "access", "portability", "rectification"
 "processor_certificate": ""

5. Cancellation request

It is possible to cancel a GDPR request, based on its subject_request_id, but only during the pending phase.

To so submit an HTTP DELETE with subject_request_id to:[subject_request_id]?api_token=[api token]

Cancellation response

When a GDPR cancellation request is received, AppsFlyer returns an HTTP response with status code 202 and several other parameters. 

Once the cancellation of the request takes place AppsFlyer sends a postback with canceled status.

6. GDPR requests test API

This AppsFlyer’s API is a test API for the AppsFlyer’s GDPR Requests API.

How does it work?

The test API works as follows:

1. Once a GDPR request has been made, the request is immediately placed in ‘Pending’ status. For testing purposes, the status changes every 30 seconds.

2. If an endpoint for a status postback has been inserted in the GDPR request, a first postback is sent right after the request and two more status postbacks are sent in 30-second intervals.

GDPR Request Test Endpoint:[api token]

Status Request Test Endpoint:[request id]?api_token=[api token]

Discovery Request Test Endpoint:[api token]

Cancellation Request Test Endpoint:[request id]?api_token=[api token]


  • A valid API token must be inserted with the request.
  • In the ‘property_id’ property, the App ID must belong to the account owner (according to the API token).

7. Request logs

The account admin can access the GDPR requests submitted in the Logs Dashboard.

For completed access and portability requests, it is also possible to download the report from within this dashboard.

To access the Logs Dashboard:

  1. Go to the main dashboard and click your user name.
  2. Click Logs and the following window opens:


8. GDPR API return codes and error messages

The GDPR API HTTP return codes and error messages are detailed in this section. 

Return code Description
201 Created
202 Cancelation request received

Bad request. The body contains the error code and message as listed in the table that follows.

GDPR API return codes

HTTP return code 400 - bad request

Messages having return code 400 contain a JSON with the error code and message.

{ "error": { "code":400, "af_gdpr_code": "%AF error code%", "message":"%error message text%" } }

Error code

Error description (message)

e111 Rate limit exceeded
e211 Unable to cancel request with invalid status
e212 Request not permitted. Erasure is in progress for the identifier.
e213 Request already exists
e214 Request not found
e311 Invalid request content-type
e312 Invalid API version
e313 Invalid subject_request_id
e314 Invalid submitted_time format
e315 Invalid status_callback_url length
e316 Invalid status_callback_url format
e317 Invalid app_id format
e318 Invalid identity_type
e319 Application platform does not match identity types
e320 Invalid identity_type
e321 LAT users are not supported via api
e322 Invalid subject_request_type
e323 Invalid subject_identities format
e324 Invalid subject_identities length
e325 Invalid subject_identities value
e411 AppID is incorrect or does not belong to your account
e412 No permissions to cancel erasure request
e413 No permissions to view request
e511 Internal problem, wait 60 minutes and try again. If the problem persists contact AppsFlyer support. 
Return code 400 bad request messages


  • Rate limitation: 80 GDPR requests every 2 minutes at the account level. 
Was this article helpful?