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 OpenDSR (Data Subject Request) 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, Schönhauser Allee 180, 10119 Berlin, Germany (contact; +49-30-166373500).

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 OpenDSR initiative

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

OpenDSR is an open-source framework, that facilitates 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.

Learn more about the OpenDSR initiative.


DSR 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

DSR requirements

DSR 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 are required 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 requires App Owners to remove personal data within 14 days of receiving the request.

The data is deleted

AppsFlyer GDPR Requests API

Use the GDPR Requests API as described in this section to implement DSR 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. At this point, the request can't be canceled.
  6. Within 14 days (see note below), AppsFlyer fulfills the request, and the request status updates to completed. AppsFlyer sends a status change postback.
    • 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).

    Note: This 14-day period begins once the 48-hour pending period has ended. Thus, the total period for fulfilling the request is 16 days after the App Owner submits the request to AppsFlyer.

GDPR request format

A GDPR Request API can be submitted via HTTP POST to the following endpoint:

For the API authorization, use the same V2 API token as for Pull API. An admin user can retrieve the token from the API token page in the dashboard. Add the token into the request header as follows: 'Authorization': 'Bearer %AuthTokenV2%'


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 No, but recommended
  • An array of up to 3 endpoints for status callbacks to be sent to the following request status changes.
  • Only HTTPS endpoints are supported.
  • Invalid URLs are rejected.


Value is one of the supported DSR platforms:
android, ios, web, windowsphone


For a CTV, PC, or Console platform request, include any of the following platforms: 


Subject_identities objects

Object type Mandatory Description
identity_type Yes
  • The identity type in string format for android, ios, web, windowsphone platforms are any of the following: 
    • ios_advertising_id
    • android_advertising_id
    • fire_advertising_id
    • microsoft_advertising_id
    • appsflyer_id 
  • The identity type in string format for CTV, PC, and Consoleplatforms: 
    • appsflyer_id 
    • customer_user_id (CUID)
  • 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 

Example of an erasure request for android, ios, web, windowsphone platforms:

curl --location --request POST '' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer %AuthTokenv2% \ --data-raw '{ "subject_request_id":"f4e5a271-f25e-4107-b681-************", "subject_request_type":"erasure", "submitted_time":"2020-07-05T10:00:00Z", "platform": "android", "subject_identities":[ { "identity_type":"android_advertising_id", "identity_value":"55*****-****-****-************", "identity_format":"raw" } ], "api_version":"0.1", "property_id":"com.*********.*******.********", "status_callback_urls":[ "" ] }'

Example of an erasure request forCTV, PC, and Console platforms:

curl --location --request POST '' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer %AuthTokenv2% \ --data-raw ' {"requester": "", "subject_request_id":"valid-uuid4-string", "subject_request_type":"erasure", "submitted_time":"2020-07-05T10:00:00Z", "subject_identities":[ { "identity_type":"appsflyer_id", "identity_value":"valid-appsflyer-id-string", "identity_format":"raw" } ], "api_version":"0.1", "property_id":"app-id", "platform": "roku", "status_callback_urls":[ "" ] }'


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\": \"\"," +
  "\r\n\"subject_request_type\": \"erasure\"," +
  "\r\n\"platform\": \"android\"," +
  "\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\": \"\"," +
  "\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")
  .addHeader("Authorization: Bearer", "")

  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:<req_id>

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",

Validate postback

To validate the authenticity of incoming postbacks:

  1. Create an allowlist of all the processor domains that you allow to make callbacks.
  2. If the header value for X-OpenGDPR-Processor-Domain is in your allowlist, fetch the certificate.
    • The certificate URL is the value of processor_certificate in the /discovery response body.
    • You can also fetch the certificate directly from the AppsFlyer endpoint using the V2 API token as a bearer token in the authorization header: GET
  3. Validate the certificate using a library to confirm that the certificate:
    1. Is issued by a trusted authority.
    2. Is issued to the same string provided in the X-OpenGDPR-Processor-Domain header value.
    3. Isn’t expired.
  4. Once you confirm the certificate is valid, use it to validate the X-OpenGDPR-Signature header against the raw request body. AppsFlyer uses SHA256 RSA as a signing algorithm.
  5. Get a response in the status header:
    1. 202 Accepted if validation is successful. 
    2. 401 Unauthorized if the signature fails to validate or the processor domain isn’t in your allowlist.

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]

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

4. Discovery request-in process

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

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 submit an HTTP DELETE with subject_request_id :<req_id>

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 the canceled status.

6. GDPR requests test API

This AppsFlyer 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: POST

Status Request Test Endpoint: GET

Discovery Request Test Endpoint: GET

Cancellation Request Test Endpoint: DELETE

Certificate Test Endpoint: GET

Access/Portability Reports Test Endpoint: GET


  • A valid V2 API token must be inserted into the request header as follows: 'Authorization': 'Bearer %AuthTokenV2%'
  • In the ‘property_id’ property, the App ID must belong to the account owner (according to the API token).

7. Request logs

An admin user 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. From the top bar, open the account menu (email address dropdown) > Logs.
  2. 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. 

GDPR API return codes

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.

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%" } }

Return code 400 bad request messages

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. 

Traits and limitations

  • The UI displays up to 200 randomly selected requests.
  • Checking the status of a request from more than 60 days ago returns "request not found".