> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xquik.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Twitter campaign verification API workflow

> Verify giveaway follows, retweets, replies, quotes, winners, and participant exports through one reviewable Twitter campaign workflow with audit rows.

<blockquote className="agent-llms-directive">
  For the complete documentation index, see <a href="/llms.txt">llms.txt</a>.
</blockquote>

Use this workflow when a campaign needs one reviewable row per participant.
Choose the narrowest check first. Use a draw when winners need selection.

Campaign verification separates entry collection, rule checks, winner selection,
and publication. Store one campaign ID across every stage. Keep source Tweet
IDs, participant user IDs, filters, cursors, timestamps, and verification states.
Without these checkpoints, the review cannot trace each decision.

## Pick the proof path

<CardGroup cols={2}>
  <Card title="Follow task" icon="user-check">
    Use `GET /api/v1/x/followers/check?source={participant}&target={brand}` to
    check one participant and one target account.
  </Card>

  <Card title="Retweet task" icon="repeat-2">
    Use `GET /api/v1/x/tweets/{id}/retweeters` to page retweeters.
  </Card>

  <Card title="Reply or quote task" icon="messages-square">
    Use `GET /api/v1/x/tweets/{id}/replies` for replies.
    Use `GET /api/v1/x/tweets/{id}/quotes` for quote posts.
  </Card>

  <Card title="Giveaway selection" icon="trophy">
    Use `POST /api/v1/draws` for winner selection and published filters.
  </Card>
</CardGroup>

Translate every published participation rule into one documented check.
Use follower relationships for follow rules. Use retweeter pages for repost
rules. Use reply rows for keywords, hashtags, and mentions. Use quote rows when
quotes define campaign participation. Store the endpoint and checked time beside
each result. Never infer one campaign activity from another activity.

Complete every required check before winner selection begins. A participant can
pass one rule and fail another. Keep accepted and rejected states separately.
An operator can then explain every inclusion and rejection later.

## Choose the focused picker guide

Use the [Twitter giveaway picker guide](/guides/twitter-giveaway-picker) for
random winner selection, backups, exports, and public result URLs.

Use the [comment and retweet picker guide](/guides/twitter-comment-retweet-picker)
for reply authors, retweeters, hashtags, cursors, and stable user IDs.

## Follow check

Check one relationship at a time. Store both handles, the result, and time.

A follow check proves one source-to-target relationship at one checked time.
Store the source handle, target handle, stable user IDs, and response state.
Repeat the same request only when the first read is uncertain.
Do not treat follower counts as proof for one participant.

Use separate rows when campaigns require several target accounts.
One successful relationship then cannot satisfy every follow rule.

```bash theme={null}
curl "https://xquik.com/api/v1/x/followers/check?source=participant_handle&target=username" \
  -H "x-api-key: xq_YOUR_KEY_HERE" | jq
```

## Tweet-level checks

Use tweet endpoints when one source tweet defines campaign participation.
Keep each cursor with its participant page.

Retrieve every available reply, retweeter, or quote page before evaluation.
Save each page before requesting the next cursor. Normalize participants to
stable X user IDs. Then join required activities by that stable key.

Remove duplicate authors only when published uniqueness rules require it.
Keep rejection reasons for missing replies, retweets, quotes, or required text.
Do not replace missing proof with displayed engagement counts.

<CardGroup cols={3}>
  <Card title="Retweeters" icon="repeat-2">
    `GET /api/v1/x/tweets/{id}/retweeters`
  </Card>

  <Card title="Replies" icon="messages-square">
    `GET /api/v1/x/tweets/{id}/replies`
  </Card>

  <Card title="Quotes" icon="message-square-quote">
    `GET /api/v1/x/tweets/{id}/quotes`
  </Card>
</CardGroup>

Page until `has_next_page` is `false`. Pass `next_cursor` back as `cursor`.
Store the campaign ID with every page.

## Giveaway draw

Use the Draws API when campaign rules require winner selection.
Define every filter before entries close. Never add hidden rules afterward.

Record the number of winners and backup winners before running a giveaway.
Random selection starts only after every published check completes.
Do not randomly pick from an unchecked participant list.
Do not pick multiple winners by repeating uncertain create requests.

Save the original draw request and returned draw ID right away.
Poll that stored draw until completion or failure. Export inspected entries and
selected winners as separate records. Reconcile exported row counts with the
stored request before publishing results.

```bash theme={null}
curl -X POST https://xquik.com/api/v1/draws \
  -H "x-api-key: xq_YOUR_KEY_HERE" \
  -H "Content-Type: application/json" \
  -d '{
    "tweetUrl": "https://x.com/example_user/status/1893704267862470862",
    "winnerCount": 3,
    "backupCount": 2,
    "uniqueAuthorsOnly": true,
    "mustRetweet": true,
    "mustFollowUsername": "username",
    "requiredKeywords": ["entered"]
  }' | jq
```

Export inspected participants with `type=entries`. Export selected winners with
`type=winners`.

```bash theme={null}
curl "https://xquik.com/api/v1/draws/f4bd00a2-7b4e-4e59-8e1b-72e2c9f12345/export?format=csv&type=entries" \
  -H "x-api-key: xq_YOUR_KEY_HERE" \
  -o campaign-entries.csv
```

## Store one audit row

Use stable user IDs as keys. Display names and handles can change.

One audit row should answer who, what, when, and how.
Store the participant ID, source Tweet ID, proof endpoint, cursor, and state.
Add the campaign ID and checked timestamp. Keep the published rule that required
the check. Keep rejection reasons without exposing private operator notes.

```json theme={null}
{
  "campaign_id": "spring-launch-2026",
  "x_user_id": "9876543210",
  "username": "participant_handle",
  "tweet_id": "1893704267862470862",
  "proof_endpoint": "GET /api/v1/x/followers/check",
  "proof_cursor": null,
  "verification_state": "matched",
  "checked_at": "2026-05-24T19:30:00.000Z"
}
```

## Handle costs and retries

<Check>
  Xquik meters direct X read endpoints. Budget by participants and pages.
</Check>

<Check>
  Draw execution can meter tweet, reply, retweeter, and follow checks.
</Check>

`402 insufficient_credits` stops the audit. Fund or narrow it first.

Repeat an uncertain read with the same tweet, filter, and cursor.
Search draw history before repeating an uncertain create request.

Estimate costs from participant checks and expected pagination.
Store completed pages so retries never restart the whole campaign audit.
Stop on `402 insufficient_credits`. Add credits or narrow the participant set.
Respect `429` backoff before repeating reads. Never change campaign rules to
avoid a billing or rate-limit response.

## Next steps

<CardGroup cols={2}>
  <Card title="Create draw" icon="trophy" href="/api-reference/draws/create">
    Run a giveaway draw with published eligibility filters.
  </Card>

  <Card title="Export draw" icon="download" href="/api-reference/draws/export">
    Export winners or all inspected entries.
  </Card>

  <Card title="Check follower" icon="user-check" href="/api-reference/x/check-follower">
    Verify one source and target relationship.
  </Card>

  <Card title="Get retweeters" icon="repeat-2" href="/api-reference/x/retweeters">
    Page users who retweeted one campaign tweet.
  </Card>
</CardGroup>

<div className="related-api-links">
  <Accordion title="Related follower, list & community APIs" icon="link">
    * Profiles: [Search users](/api-reference/x/search-users) · [Search autocomplete](/api-reference/x/search-autocomplete) · [Get user](/api-reference/x/twitter-profile-lookup) · [Batch users](/api-reference/x/batch-users)
    * Followers: [Followers](/api-reference/x/followers) · [Following](/api-reference/x/following) · [Follower IDs](/api-reference/x/follower-ids) · [Following IDs](/api-reference/x/following-ids) · [Creator subscriptions](/api-reference/x/user-subscriptions) · [Affiliates](/api-reference/x/user-affiliates) · [Similar accounts](/api-reference/x/user-similar) · [Verified followers](/api-reference/x/verified-followers) · [Followers you know](/api-reference/x/followers-you-know) · [Check follower](/api-reference/x/check-follower)
    * Lists: [Search lists](/api-reference/x/search-lists) · [User lists](/api-reference/x/user-lists) · [List memberships](/api-reference/x/user-list-memberships) · [List members](/api-reference/x/list-members) · [List followers](/api-reference/x/list-followers)
    * Communities: [Find](/api-reference/x/community-find) · [Popular](/api-reference/x/community-popular) · [Topics](/api-reference/x/community-topics) · [Suggested](/api-reference/x/community-suggested) · [Details](/api-reference/x/community-info) · [Members](/api-reference/x/community-members) · [Moderators](/api-reference/x/community-moderators) · [Timeline](/api-reference/x/community-tweets) · [Media](/api-reference/x/community-media) · [Keyword search](/api-reference/x/community-search)
  </Accordion>
</div>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.