interaction

Answering an interaction, and everything after the answer.

Every route here takes a Responder, which holds the two ids and the token as one value: the token in the path is the credential, so these calls go out with no Authorization header whatever the rest.Config holds, and a 401 is about that path token (error.invalid_webhook_token, which error.is_path_token_dead answers True for), never about the bot token. An expired interaction is not a 401: it is one of the codes below.

The follow-up routes are api/webhook’s with thread: None wired in. Discord does not accept thread_id on an interaction follow-up, and the token already says which channel the message lands in.

Deadlines, which glyde has no clock to enforce:

Deadline	Value	Miss it and
first response	3 seconds	the token dies, later calls are `10062`
token lifetime	15 minutes	follow-ups are `10015`
responding twice	any time	`40060`

A follow-up straight after a deferred response edits the original instead: no message is created and the ephemeral flag is ignored. Discord calls that deprecated, so use edit_original_response.

Types

Responder

opaque </>

Who to answer. One value, because the ids and the token have to come from the same interaction: the Id tags catch an id swapped for an id, and this catches the token of the other interaction in flight.

pub opaque type Responder

Values

callback

</>

pub fn callback(
  responder: Responder,
  body: body.Body,
) -> rest.Call(Nil)

POST /interactions/{interaction.id}/{token}/callback, the first answer. Answers 204: use callback_with_response if you need the message id.

callback_with_response

</>

pub fn callback_with_response(
  responder: Responder,
  body: body.Body,
) -> rest.Call(interaction.InteractionCallbackResponse)

POST /interactions/{interaction.id}/{token}/callback?with_response=true, answering 200 with the callback resource instead of 204.

create_followup

</>

pub fn create_followup(
  responder: Responder,
  body: body.Body,
) -> rest.Call(message.Message)

POST /webhooks/{application.id}/{token}?wait=true, an extra message on the same interaction. Capped at five when the app is user-installed and not a member of the server, 40094 past that.

delete_followup

</>

pub fn delete_followup(
  responder: Responder,
  message: id.Id(id.Message),
) -> rest.Call(Nil)

DELETE /webhooks/{application.id}/{token}/messages/{message.id}.

delete_original_response

</>

pub fn delete_original_response(
  responder: Responder,
) -> rest.Call(Nil)

DELETE /webhooks/{application.id}/{token}/messages/@original, which works on an ephemeral response as well.

edit_followup

</>

pub fn edit_followup(
  responder: Responder,
  message: id.Id(id.Message),
  body: body.Body,
) -> rest.Call(message.Message)

PATCH /webhooks/{application.id}/{token}/messages/{message.id}.

edit_original_response

</>

pub fn edit_original_response(
  responder: Responder,
  body: body.Body,
) -> rest.Call(message.Message)

PATCH /webhooks/{application.id}/{token}/messages/@original. Turns a deferred response into a real one, and edits one already sent.

get_followup

</>

pub fn get_followup(
  responder: Responder,
  message: id.Id(id.Message),
) -> rest.Call(message.Message)

GET /webhooks/{application.id}/{token}/messages/{message.id}.

get_original_response

</>

pub fn get_original_response(
  responder: Responder,
) -> rest.Call(message.Message)

GET /webhooks/{application.id}/{token}/messages/@original.

responder

</>

pub fn responder(
  interaction interaction: id.Id(id.Interaction),
  application application: id.Id(id.Application),
  token token: interaction.InteractionToken,
) -> Responder

The HTTP-interactions path, and a token kept somewhere across a restart. Prefer responding_to where there is an Interaction to hand.

responding_to

</>

pub fn responding_to(
  interaction: interaction.Interaction,
) -> Responder

The gateway path. Everything comes off the one INTERACTION_CREATE, so the three cannot disagree.