Confirming Requesters

Some requests are held until the customer proves the email address they gave, for example a request submitted through a form under an address that has not been confirmed yet. DevStride normally emails them a confirmation link. In headless mode it sends you a request_confirmation message instead, and your tool does the confirming.

1. A customer.message arrives with kind request_confirmation. Keep data.message.verificationToken.
2. Ask the customer to confirm their address in your own tool, in whatever way you trust.
3. Once they have, call POST /service-desk/requesters/confirm with the token.

This does exactly what the customer clicking DevStride's own link would: the request is released into your queue, the requester becomes active, and every other request of theirs still held is released with it. The address is proven, not just the one request.

Needs: Manage Requesters.

Request

curl -X POST "https://api.devstride.com/v1/organizations/$ORG_ID/service-desk/requesters/confirm" \
  -u "$DEVSTRIDE_API_KEY:$DEVSTRIDE_API_SECRET" \
  -H "Content-Type: application/json" \
  -d '{ "token": "EXAMPLE-TOKEN-not-a-real-value" }'

Response

{
  "confirmed": true,
  "requesterId": "1c6e8a4b-3d9f-4b2e-8a7c-5f0d2b9e6a41",
  "itemNumber": "I4823"
}

What to know

• It is safe to repeat. Confirming the same token again returns the same answer and changes nothing.
• It never reinstates a blocked or erased requester. The request is released, but a requester your team blocked stays blocked.
• The token works only in the organization that issued it.

Refusals