TEASEDocs
ProductsClubHow-to

Request custom or proof content from the model

Ask the model (via Telegram) for a specific proof/custom clip for one fan, then mark it delivered.

Who this is for: chatters, mid-conversation with a fan.

A content request is a small state machine that hands a specific ask off to the model — "proof" (verify you're really her) or "custom" (a fan-specific clip) — and tracks it through to delivery.

stateDiagram-v2
    [*] --> pending: chatter creates
    pending --> filming: model starts
    pending --> declined: model declines
    filming --> declined: model declines
    pending --> fulfilled: model fulfills
    filming --> fulfilled: model fulfills
    fulfilled --> delivered: inbox confirms send
    pending --> cancelled: chatter cancels
    filming --> cancelled: chatter cancels
    pending --> expired: sweeper (stale)
    filming --> expired: sweeper (stale)

Create the request

curl -X POST "https://app.tease.link/api/admin/requests" \
  -H "Authorization: Bearer $TEASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"fan_id": "12345", "kind": "proof", "priority": "normal", "text": "wants a wave proof"}'
FieldTypeDescription
fan_idstringRequired.
kind"proof" | "custom"Defaults to proof.
priority"normal" | "urgent"urgent prefixes the model's Telegram alert with 🔴 and sorts first in the list.
textstringUp to 2000 chars — what the fan is asking for.
operator_idintegerThe chatter creating the request.

Creating a request immediately alerts the model on Telegram in a background thread — the API call itself doesn't wait on that delivery.

Track and respond

curl "https://app.tease.link/api/admin/requests?status=pending" \
  -H "Authorization: Bearer $TEASE_API_KEY"

The model side (usually driven from the Telegram bot) moves the request forward:

curl -X POST "https://app.tease.link/api/admin/requests/{request_id}/respond" \
  -H "Authorization: Bearer $TEASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "fulfill", "media_ids": ["88120"]}'

action is start (→ filming), fulfill (→ fulfilled, attaches media_ids), or decline (→ declined, with a reason). Re-sending the same terminal action is idempotent — it returns the request unchanged rather than erroring. An invalid transition (e.g. fulfilling an already-declined request) is a 404.

Close it out

Once the fulfilled media has actually been sent to the fan:

curl -X POST "https://app.tease.link/api/admin/requests/{request_id}/deliver" \
  -H "Authorization: Bearer $TEASE_API_KEY"

Or cancel an open request the fan no longer wants:

curl -X POST "https://app.tease.link/api/admin/requests/{request_id}/cancel" \
  -H "Authorization: Bearer $TEASE_API_KEY"

Both return a 409 if the request isn't in the right state (deliver needs fulfilled; cancel needs pending or filming).

A background sweeper independently expires requests that sit open too long (pending or filming past their age limit) into expired, so nothing hangs open indefinitely if the model never responds.

What's next

Once delivered, the fulfilled media is a real vault item like any other — find it with Find content to send.

On this page