Users

GET /v1/users lists the people in your company. It exists for one practical reason: so your integration can offer a "send as" picker instead of hard-coding one sender, and then pass the chosen person's email as sender_email when it sends.

Requires the users:read scope. Read-only — there is no endpoint to invite, change, or remove a member.

Query parameters

Example request

curl "https://api2.bunnydoc.com/v1/users?status=accepted&per_page=100" \
  -H "Authorization: Bearer <access_token>"

GET /v1/users?status=accepted&per_page=100 HTTP/1.1
Host: api2.bunnydoc.com
Authorization: Bearer <access_token>

Response

{
  "data": [
    {
      "id": "018f6b2c-3d4e-7f5a-8b6c-7d8e9f0a1b2c",
      "email": "dana@yourco.com",
      "first_name": "Dana",
      "surname": "Lee",
      "name": "Dana Lee",
      "role": "admin",
      "status": "accepted",
      "products": ["eSign"]
    }
  ],
  "pagination": { "page": 1, "per_page": 25, "total": 1, "total_pages": 1 }
}

Picking a valid sender

Not everyone in the list can send. For sender_email to resolve, the member must be both:

• status = accepted — a pending invitee or an archived member is not an active user, and
• holding an eSign seat — check that products contains eSign.

Filter on both before offering someone in a picker:

const res = await fetch(
  "https://api2.bunnydoc.com/v1/users?status=accepted&per_page=100",
  { headers: { Authorization: `Bearer ${token}` } },
);
const { data } = await res.json();

const senders = data.filter((u) => u.products.includes("eSign"));

Anything else gives you 422 sender_not_found at send time.

One case this list can't warn you about: a member can have an accepted membership while their user account has been deactivated. That isn't exposed here, so treat 422 sender_not_found on an otherwise-eligible member as "this person can no longer send" and fall back to another sender or to the key owner.

Errors

Next steps