Users API

Read your team, and manage verified caller-ID numbers.

Method	Path	Scope
GET	/users	users:read
GET	/users/{id}	users:read
GET	/users/{id}/verified-numbers	users:read
POST	/users/{id}/verified-numbers/send-code	users:write
POST	/users/{id}/verified-numbers/verify	users:write

List your team

curl https://app.limecall.com/api/v1/users \
  -H "Authorization: Bearer sk_live_..."

Read-only. Inviting, removing and changing roles are dashboard-only — see Team & roles.

Verified numbers

A user can display a number they own outside LimeCall as caller ID, but only after proving they control it. That is a two-step flow, and it is the one genuinely interesting thing in this resource.

1. Send the code

curl -X POST https://app.limecall.com/api/v1/users/u_2841/verified-numbers/send-code \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"phoneNumber":"[phone]"}'

LimeCall calls or texts that number with a code.

2. Confirm it

curl -X POST https://app.limecall.com/api/v1/users/u_2841/verified-numbers/verify \
  -H "Authorization: Bearer sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"phoneNumber":"[phone]","code":"418293"}'

3. Check what is verified

curl https://app.limecall.com/api/v1/users/u_2841/verified-numbers \
  -H "Authorization: Bearer sk_live_..."

Someone must be able to answer that number to complete step 2. This is a carrier anti-spoofing requirement, not a LimeCall policy, and there is no way around it — including from the API.

Use this when onboarding staff programmatically: create the user in your own system, then drive verification from your onboarding flow instead of asking each person to find the setting.

See Caller ID.