SDK APIs

To work with the DT Offer Wall, you must ensure that you have:

DT Offer Wall Sample App

If you prefer to jump straight to the code, DT's sample app can assist you in using DT Offer Wall within your app. In addition, use the DT sample app as a reference during implementation to troubleshoot possible integration issues.

To download the app, click on the relevant platform tab.

Before Starting the SDK

User ID

DT Offer Wall SDK will generate a unique User ID upon starting the SDK.

If, instead, you want to provide the SDK with your User ID, you will need to use the following API before starting the SDK:

Kotlin
OfferWall.userId = "userId"
Java
OfferWall.setUserId("userId");

The User ID is stored across SDK sessions.

This API can be called at any point after starting the SDK. The new user ID will be associated with any future action by the user.

Privacy and Compliance

GDPR

The General Data Protection Regulationarrow-up-right requires you to scope your user's consent.

A user is within the GDPR scope for your app when one or all of the following apply:

  • The user is currently located in the EU.

  • The user has registered with the app as an EU resident.

  • The app is specifically targeted to EU users.

Once you have collected the user's consent, you can pass it onto the SDK using the following API:

We recommend that the first time you gather the user's consent, you pass it onto the SDK before starting the SDK. The SDK will then consider the user's consent when initializing. In the following sessions, you must only call the API if the user updates their consent.

For more information about DT and GDPR, refer to DT's GDPR Resource Page.

CCPA

The California Consumer Privacy Actarrow-up-right of 2018 (CCPA) is intended to protect the personal information of California residents. CCPA applies to all companies doing business in California. If a California resident uses a mobile app developer's app, CCPA applies to the developer and every company that processes the personal information of the app's users. CCPA came into effect on 1 January 2020.

For more information about DT and CCPA, refer to DT's CCPA Resource Page.

Once you have collected the user's opt-out, you can pass it onto the SDK using the following API:

Google Play Families Ads Program

To comply with the Google Play Family Programarrow-up-right, you must instruct the SDK not to track the Google Ad ID in any requests for users covered by the program. By default, the DT Offer Wall SDK includes the Google Ad ID in all communications with our backend; however, to prevent this and align with the Family Program requirements, you can pass an optional boolean parameter when you start the SDK.

Starting the SDK

circle-info

Starting from FairBid 3.63.0, you will need to pass the saltToken when starting the SDK. Contact your DT Representative for information on how to set it up.

The SDK will throw a Runtime Exception if the saltToken value is null or empty.

Start the SDK using the following API to show the Offer Wall or request Virtual currency:

The offerWallListener needs to be defined and passed to the start API.

It will let the integration know when the Offer Wall is opened and closed so you can pause and resume your app accordingly. For more information about these callbacks and how to show the Offer Wall, see Showing the Offer Wall.

Showing the Offer Wall

To Show the Offer Wall, simply use the OfferWall.show API:

This will show the Offer Wall for the default placement with the default behavior (keep the Offer Wall open when the user clicks on an offer and gets redirected out of your app).

Show Options

Show Options enables you to specify the placement ID, change the default behavior of the Offer Wall, or introduce tracking parameters.

Close on Redirect

You can specify whether the Offer Wall should be closed once a user clicks on an offer. This will determine what the user sees when returning to the app: either the Offer Wall again or your app. This value is false by default, meaning the user will return to the Offer Wall.

Use the showOptions API to define the desired behavior:

Custom Parameters (Server Side Rewarding)

When using Server Side Rewarding (see Integrating via REST API - Rewards), you may want to associate additional parameters to the Offer Wall being shown for a given user/placement so that you can perform additional tracking. These custom parameters will be passed back to your system during the reward callback.

Note that these parameters' keys are limited to pub0, pub1, ..., pub9

To add these custom parameters when showing the Offer Wall, use the customParams API:

Show With Placement ID

If you're using placements in your integration, you can specify for which placement ID you want to show the Offer Wall:

Offer Wall Lifecycle Callbacks

Following Starting the SDK, you will need to set up a listener to be notified of the following Offer Wall lifecycle events:

  • Offer Wall is about to be shown.

  • The user closed the Offer Wall.

  • Offer Wall was closed unexpectedly due to an error.

Implement the listener with the OfferWallListener API:

See Errors to assess any problems that may occur (typically an integration mistake).

Rewarding the User

If you are interested in using your server to handle virtual rewards to your users, DT can interact with it after you've set up your server. For further information, see Server-Side Hosting.

Virtual Currency Settings assumes you do not run your servers and prefer relying on DT's virtual currency hosting. This is the default setting for mobile applications in the developer Dashboard.

Virtual Currency Settings

First, you must implement a VirtualCurrencySettings object and pass it to the SDK start.

The VirtualCurrencySettings holds the security token and callbacks that allow for the complete client-side rewarding:

Requesting Virtual Currency

Run the requestCurrency API to request Virtual Currency:

This will request the server for the delta (amount since the last transaction) of the default virtual currency the current user is eligible for.

Virtual Currency Options

The request may include the following additional configurations:

  • Specify the currency ID if using multiple currencies in your app.

  • Specify if the SDK should show a Toast notification of the virtual currency amount received (shown by default).

Handling a Virtual Currency Success Response

You can extract the delta of coins received by the user as well as the currency name and ID from the VirtualCurrencySuccessfulResponse object:

Virtual Currency Errors

When there is a problem with the request, you can assess what's wrong by inspecting the VirtualCurrencyErrorResponse object:

Errors

The following table describes some of the possible errors that might occur when you show the Offer Wall or request virtual currency:

ERROR
DESCRIPTION

CONNECTION_ERROR

It can occur when either showing the Offer Wall or requesting virtual currency when the device is offline.

INVALID_VIRTUAL_CURRENCY_RESPONSE

If the virtual currency request is successful but not in the expected format, this may be a consequence of an integration mistake or a system problem. If this occurs, please contact an account manager or Solution Engineer.

INVALID_VIRTUAL_CURRENCY_RESPONSE_SIGNATURE

If the virtual currency response is incorrectly signed. This may indicate either an interference with the SDK<>backend communication (e.g., a man in the middle) or a system problem. Please contact an account manager or solution engineer if you detect this error in production.

VIRTUAL_CURRENCY_SERVER_RETURNED_ERROR

This typically indicates that the backend rejected the virtual currency request due to missing parameters or a wrong signature. Double-check your integration. If the problem persists, contact an account manager or Solution engineer.

DEVICE_NOT_SUPPORTED

Android Only: If you are trying to run the SDK on a device running Android OS lower than 4 (API 16 - Jelly Bean).

UNKNOWN_ERROR

The server returned an error that the SDK does not recognize.

Last updated