Skip to documentation
AdQuestDocs

Custom evidence

API type: custom. Own-platform only. Define an outcome using an allowlisted evidence model.

On this page

Submit evidence and read status

Start the quest without a media timer and read getCustomStatus(id). Submit evidence of the configured type only. For host_verified, set the supported capability to granted only when your backend has actually verified the outcome. Changing a browser flag alone is not sufficient.

Manual-review example
const result = await questRequest(config, questId, "complete", {
  evidence_type: "manual_review",
  evidence: participantEvidence,
});
// An accepted submission can return completed: false and custom.status: pending.
const status = await client.getCustomStatus(questId);
// After approval, request completion again to settle the quest.

Implement URL callback verification

Set a public HTTPS callback URL in the custom quest rule. When completion needs verification, AdQuest sends a JSON POST with quest_id, platform_id and external_user_id. Look up the outcome in your own backend and return a successful HTTP response with verified: true only when that user actually qualifies. This callback is a read-only verification query, not a command to grant rewards.

Successful callback response
{ "verified": true }

Return verified: false when the outcome is missing. The verifier does not follow redirects, allows a 2-second connection timeout and 4-second total timeout, and accepts responses up to 8 KB. Callback requests do not use the outgoing webhook signing contract; avoid returning participant data or performing mutations. Alternatively, an allowed signed server event can supply evidence before completion.

Verify the review lifecycle

  • Test missing evidence, a mismatched evidence type, a pending review and an approved review.
  • Show the server’s rejection reason and allow appropriate correction.
  • Do not execute arbitrary publisher code as custom quest evidence.

Next steps

Something unclear, missing or wrong here? Tell us