Slack and Lyft: Making /Lyft Move You

Like, physically. And maybe emotionally.

A year ago, we unveiled both the Lyft Developer Platform and the ability to request Lyft rides via Slack. And @everyone was :joy:-ful and all was :100:!

While we explained how one could request rides in Slack we didn’t explain how it all worked. In this post we’ll remedy that with a technical spotlight on Lyft’s Slack integration for the benefit of Lyft Developers everywhere.

You Could Have Made This

Our Lyft+Slack bot uses the Lyft Public API, which means — remarkably — anyone could have built it. All that’s needed is a careful perusal of our Developer Documentation, the Slack Documentation, and some elbow/brain grease.

How We Made This

For our Slack App integration, we chose a Python application. In the interest of brevity, we’ll walk through a single codepath below to showcase the app’s general development pattern. Let’s take a look at the methods behind the `/ride` command.

We’ve skipped a bit of code here, but this is the real core of interpreting ride requests. self is an object representing the command handler, words is a list of space-delimited strings from the raw text of the slack command, model represents a user-specific data model (including things like API tokens and slack IDs), and ride_type is the kind of Lyft the user is requesting…could be a lyft, a lyft_line, or a lyft_plus. Let’s walk through this piece by piece, highlighting particular functions (and diving in where necessary).

valid_input, pickup_address, destination_address, error_message =
  if not valid_input:
return error_message

The first piece of code in this method ensures that this is a valid ride request command. If it is valid, it interprets the pickup_address and destination_address (which could include shortcuts defined in the data model like a user’s home or work). Otherwise, it returns an error message. We won’t dive into the self._validate_command method, but its behavior is described succinctly in the _validate_command method comment:

 def _validate_command(words):
# basic input validation
# we are expecting
# ‘ride [pickup address] to [destination address]’
# ‘line [pickup address] to [destination address]’
# ‘plus [pickup address] to [destination address]’
# address can be ‘home’ or ‘work’

Next, we check if the pickup_address or destination_address requires confirmation.

pickup_location, must_confirm_pickup =
self._get_pickup_location(pickup_address, model)
  destination_location, must_confirm_destination =
self._get_destination_location(destination_address, model)
  if must_confirm_pickup or must_confirm_destination:
model.get_token(), model.slack_id, ride_type)
return self._render_address_confirm(pickup_location,

return self._request_ride(pickup_location, destination_location,
model.get_token(), model.slack_id, ride_type=ride_type)

If this is the first ride request a user makes, we need to ensure they typed in the correct address. So in this code snippet, we’re checking the pickup_location and destination_location and checking if they require confirmation. If they do, we save the current ride request to our model and render the confirmation request — i.e., we send text through Slack asking whether they want to confirm their addresses.

Once they /confirm we’re off to the races, and call the _request_ride method. Here it is below:

And lo and behold, the public API is here! Here we make two API calls: first we use the Availability — Ride Types API to make sure the ride_type is available for that user. If not, the _check_ridetype_availability method will raise an error that will bubble up to the user.

We are using Redis as a temporary persistence layer for a given user’s slack_id and model. Then we call the Rides — Request API to actually request the ride. If all goes well, we clear the current ride request in Redis, store a response_url where a user can track their ride, and send a success message to the user.

So how does the publicapi.request_ride method actually integrate with the API? Another deep dive into that method is instructive:

The code is pretty easy to follow. First we add the destination if applicable, and do a little bit of client-side error checking if this is a lyft_line. We then add a primetime_confirmation_token if necessary, then add the users’ bearer token to the Authorization header. Then we simply POST to the API with the necessary fields, log possible errors, and return the JSON response to the parent caller.

Inspired to learn more about the API? Want to make your own Slack app with Lyft integration? Go for it! Check out our Developer Portal and Developer Documentation, and keep posted here for more Lyft Developer examples and updates.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.