# Custom evidence

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

Source: https://dashboard.adquest.batriders.ir/docs/quest-evidence/custom · Audience: Developers · Section: Quest evidence

## 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**

```typescript
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.
```

- [Event proof and signatures](https://dashboard.adquest.batriders.ir/docs/quest-evidence/event): SDK events and server callback signing.

## 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**

```json
{ "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

- [Quest evidence overview](https://dashboard.adquest.batriders.ir/docs/quest-evidence): The shared request helper and the completion flow.
- [Quest actions API](https://dashboard.adquest.batriders.ir/docs/api/quest-actions): Every request and response.
- [Set up this quest in the dashboard](https://dashboard.adquest.batriders.ir/docs/dashboard/quests/custom): For publishers: configure and publish the quest.