Get started
How AdQuest works
Who does what, which credential lives where, and which integration method to choose.
On this page
Who does what
| Party | Responsibility |
|---|---|
| Your backend | Knows who the user is. Creates a participant session with the Secret Key, receives webhooks, keeps every secret. |
| Your frontend | Shows the widget or your own interface, using the public API key and the user’s participant token. |
| AdQuest | Serves quests and lotteries, checks each completion on its servers, settles tokens and sends webhooks. |
AdQuest never signs your users in. It trusts the user ID your backend sends. The participant token is short-lived (15 minutes) and is tied to that one user.
What AdQuest decides, and what you decide
| AdQuest decides | You decide |
|---|---|
| Whether a quest was completed, and the reward | Who the user is (external_user_id) |
| Which quests a user can see | The language (locale) and the reward country (country_code) |
| Token balances, lottery entries and draws | Where AdQuest appears in your product |
| When a webhook is sent | What your own product grants after a verified result |
Choose an integration method
| Method | Best for | You build | Guide |
|---|---|---|---|
| React widget | React or Next.js apps. The fastest start. | A session route and one component. | React & Next.js |
| Hosted iframe | Any website. | A session route and a postMessage handler. | Hosted iframe & WebView |
| Native WebView | iOS, Android, React Native and Flutter apps. | A session endpoint and a native bridge. | Hosted iframe & WebView |
| Headless client | A fully custom interface. | A session route and your own screens on the typed client. | Headless JavaScript |
| API only | Any other server or client. | HTTP calls to the public API. | API reference |