Manage access requests through the APIBeta

When a brand asks visitors to request access, each request appears in the brand's Requests tab. The API gives you the same list and the same decisions. The token needs the brands:requests scope.

List requests

GET /api/v1/brands/{brand}/requests returns data and next_cursor. Each request has id, kind, name, company, email, message, status, created_at and decided_at. Filter with ?status=pending, approved or rejected. Use limit and cursor to page through them.

curl -H "Authorization: Bearer $TARKLE_TOKEN" \
  "https://tarkle.com/api/v1/brands/aspire/requests?status=pending"

Approve or reject

POST /api/v1/brands/{brand}/requests/{request} with { "action": "approve" } or { "action": "reject" }. The response contains the request id and its new status.

curl -X POST \
  -H "Authorization: Bearer $TARKLE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"action":"approve"}' \
  https://tarkle.com/api/v1/brands/aspire/requests/REQUEST_ID

What each decision does

• Approving a download request gives the person a download link and emails it to them. The response includes emailed, which says whether the email was sent.

• Approving a view request only marks it approved. A view request has no link to send, so you share the brand's password with the person yourself.

• Rejecting a request marks it rejected and takes back any link that was issued.

This is the same decision as the Requests tab and the approve and reject buttons in Slack, so you can use any of the three.