Users Management

There are two ways we can look at the Users entity. If you’re integrating with Cabify to sync your system with the Cabify system, then each User most likely represents one of your employees with a Cabify account associated with your company. Through our API, as you’ll see you’ll be able to create, read, update and disable your users.

In turn, if you're integrating with Cabify to use the Ride Hailing services (order journeys, create estimates) then a User can represent either a passenger or the one creating journey (jump to CreateJourney API to get more details).

Activation and account access

When a User is created via the API, they receive a welcome email inviting them to set a password and log in. Until they do so, the User is in a pending state (see the state filter on Get Users).

This activation step is only required if that person needs to log into Cabify's own apps or web platform directly. It is not required to request journeys on their behalf — a pending (or even never-activated) User can still be used as a requester_id or rider.id when creating a journey.

🚧

Building a consumer-facing platform on top of Cabify?

If your end customers only take journeys booked through your own platform and never need to log into Cabify directly, consider not creating a User per customer. Instead, book their journeys as guest/external riders (see Use Case 3 in the journey creation guide), providing just a name and mobile number. This avoids managing account activation for people who never interact with Cabify, and they can still follow their journey and contact the driver through the journey's public_url, with no account or app install needed.

You can also disable the welcome email altogether for Users you do create, using send_email: false on the Create Users request.