We integrated the UberRush API as part of our multi-carrier shipping API https://goshippo.com/shipping-blog/introducing-uberrush-ship...
It's interesting to see Uber entering the space of same day delivery. Happy to chat about the integration experience if anyone is interested!
Why does your API is making such a big assumption that there is only one parcel/package per shipment[0].
I have looked at your competitors as well. Except for one all of them make this assumption. I guess customers with multi package shipments are not your target clients.
Valid question. General answer is that we and other companies in this space are fairly young companies and most of us haven't been able to tackle that problem yet. We are all working our way upstream.
I might be wrong but it seems like the api is creating one shipment for each package with in an order. I assume that mean you will get a tracking number for each package (Unless tracking number is associated with order, not the shipment in the api). The Scenario I have seen this is not something desirable. UPS[0] and Fedex[1] I believe let you ship up to 20 boxes in one shipment.
Yes, most carriers will assign a unique tracking code (and shipping label) to each shipment in the order, and also a "master" tracking code for the entire order. Depending on who the recipient is they may want to watch the entire order from the single master tracking code, or keep an eye on each individual shipment.
It's not common, but sometimes individual shipments / parcels get separated from their orders in transit, so it can be helpful to have the individual tracking codes.
All articles belong to a consignment, and a consignment has one or more articles.
There are dozens of services, the most used is eParcel which goes:
Consignment #: ABC1234567
Article #: ABC123456789123456(09999)
Both include check digits, and the extra (09999) is the destination post code so it can still be routed in cases where the address info is damaged and the central servers are not available.
This was one of the issues we struggled with as well. Ultimately we wrote our own UPS, FedEx, and USPS integrations in-house, but I can say that Shippo was incredibly responsive to our questions and requests, even going so far as to add a few of the features that were imperative to our business (and I'm sure many others.)
I still think Shippo has a long way to go, but they're doing great work and are very responsive to new ideas.
This is a game changer - not only for what service it provides, but I think it will lead to more companies making APIs for totally non-technical tasks. Sure there are companies like task rabbit, shyp, etc etc, but this is the next level of ease.
Relevant - I want an API for a cleaning service. AirBnB integration so that it can automatically track when a guest has left and the cleaner shows up within an hour to get it ready for the next guest. Would build if I didn't have so many projects going on already...
It really is. There is nothing more to say than the fact that small business owners can't afford to have a dedicated delivery service when they know demand is near 0 in some hours and through the roof in another.
I'm curious though--will small business owners bother to implement this in their website, or isn't it easier for someone else (Uber, or its competitor) to do it for them?
if you check out the bottom of the article, Uber has developed a dashboard for SMBs. But it's smart that they've opened this up to enable startups to leverage this as well as enterprise customers.
Indeed, UberRUSH exists for business end users that want to deliver their goods and products easily, especially if they don't have an app: https://rush.uber.com
The UberRUSH API exists for developers that want to go above and beyond and integrate Uber deeply into their products, services, or experiences.
A great example of this is Pythagoras (https://www.getpi.co/), a re-imagining of pizza delivery. Pythagoras doesn't have a brick and mortar storefront, and care a lot about design — so they built their own iOS app and use UberRUSH for delivery. Prior to integrating with UberRUSH, they needed to build and maintain their own fleet of delivery couriers, which limited their reach to a few neighborhoods in San Francisco. After integrating with UberRUSH, they now deliver across the city, expanding their addressable market size overnight without any additional overhead (aside from integrating the UberRUSH API into their app).
In this sense, we're offering the utility of UberRUSH to more contexts and use cases.
Well, isn't EDI just an API for manufacturing + supply chain management?
As far as retail stores are concerned, they make an API call to a supplier, and product shows up.
Granted, it's a pretty convoluted API, but I don't think it's too difficult to imagine what a supply chain algorithm would look like. Just lots of exception handling + long timeouts...
> Well, isn't EDI just an API for manufacturing + supply chain management?
EDI is more standardized data formats than API (though the fact that it often standardizes request and response formats and the relation between them makes it close to an API in some requests), and EDI goes a lot beyond manufacturing and supply chain management.
(In US healthcare financial transactions, specifically, the combination of EDI transaction specifications + standard operating rules mandated under the HIPAA is, basically, a standardized API, if not called that.)
EDI isn't so much the API but the payload's format (and its documentation). The projects I have seen usually customise the formats so much, I sometimes wonder if it's technically worth the effort to use EDI.
I'm working on a project involving EDI data right now. You speak as though you have some experience in manufacturing and data. Would you be willing to chat with me for a few minutes about the space?
I'm not sure what I could offer -- my experience is limited to wrapping my head around EDI file formats + processes, and understanding what would be required to support a small manufacturing company's who directly drop ships their products.
Given the Expense + complexity of EDI, in all cases we've found it more cost effective to integrate with all the alternate Web-based import/export tools provided by systems like VendorNet, or whatever other crazy systems our customers use.
If our volume gets bigger, we'll probably have to revisit that position, but it's served us very well for now.
Completely agree. I've looking for an API for alcohol deliver to integrate into a site I'm building and there doesn't seem to be anything great out there
I'm not sure I follow your example. Why would a cleaning service use uber? The cleaner doesn't have a car, or the uber driver will also clean your house?
Edit - I see what you mean now, more companies will make physical service API's
It would be nice to have a field to denote "This driver has a marijuana handlers permit" so they could potentially deliver recreational marijuana from retailer to consumer. Although I'm sure the regulators would want to go over this. This would be in Oregon.
I think it would also be nice to have a general interface portal for 1099-economy gigs so you can list (and document) all your qualifications and you see results from Uber, Taskrabbit, Doordash, etc that you're qualified for.
(Though naturally the bigger players there might not like sharing access to their platform like that.)
Neat. I've always wondered if Uber's ride sharing had a weak moat. As a consumer there's little difference for me between taking an Uber, Lyft, or something else. This makes it easy to compete in the consumer ride sharing market.
If Uber is able to integrate with other apps this introduces a high switching cost for those apps... and that gives them a pretty solid moat. Excited to see how this API gets used.
Why isn't it just as easy for businesses to switch to the delivery service that is cheapest at any given moment? There are API aggregators that abstract out the differences between delivery providers.
A moat is the trench around the outside of a castle that is often, but not always filled with water. It's a defensive structure because people have to cross it to get your castle in the middle. So Uber's castle (i.e. it's product) doesn't seem to be that well defended against competitors (it has a weak moat). They have the numbers and the user adoption, but fundamentally they're no different from Lyft et al.
That's my interpretation anyway! I've never heard 'weak moat' used in this context before though. Apologies if you actually know what a moat is and that all sounded rather patronising :/
> A moat is the trench around the outside of a castle that is often, but not always filled with s/water/alligators/.
Joking aside, that's a great way to describe the do-hard-things concept. I think the gp was more asking if that was a metaphor derived from some pg (or whoever) blog post.
I tend to hear the term "Rust on" (as in metal rusting). So the more rusted on you are the harder it is to get you off. The more integration you have across the board, the more rusted on you are and people can't be bothered trying to clean the rust off.
They're eagerly trying to adopt driverless cars for their fleet, they're pushing their way into disrupting most markets, and now adding a direct delivery service to their product.
Uber will be a company to watch in the coming years.
Better hope domino's doesn't enter the market. Not sure if they could since it's all franchises. But, I imagine they could price it less than $6 per delivery.
maybe not. dominos makes money from the pizza it is selling not just the delivery fee. if they had to purely make profit from delivery it might be a similar price
I'd imagine it comes down to multitasking - could Dominos successfully deliver pizza at the same time as other items? Each delivery fee would only have to make up the difference of the distance they were already traveling to the additional destination. Considering their coverage, and the fact that the drivers have central hubs and don't have to spend time idling, I think they could offer more competitive pricing while still profiting. They also have more freedom to prioritize pizza/packages as needed, where an Uber driver can't (reasonably) add a stop to their to route with a passenger in car.
Exactly this. The fact that dominoes makes money off the pizza sale just means they have a business stream to subsidize the cost of delivery to nearby locations.
Same reason Amazon can run Fresh. If you order groceries and your neighbor orders an Amazon package, just pocket the money that would've been paid to a carrier to deliver that box and get your Fresh driver to do so instead.
Also, a point-to-point delivery service requires an average of about 2 trips (pickup + dropoff) to complete a job. Pizza delivery requires an average of less than 2 trips to complete a job; the pickup trip gets spread across multiple orders.
Domino's might have wide coverage throughout the US, but in any single city, the number of drivers is tiny, maybe a few hundred at best. Uber has tens of thousands, you can't even compare their abilities to deliver. If anything a partnership with Uber might help Domino's because they could get rid of their own drivers, and each pizza could be delivered faster and warmer.
I've actually been thinking of starting a similar venture in Tunisia. Over here, there is simply no straightforward way to deliver packages within a city. Obviously I don't have the platform Uber has, so I'm thinking of building both at the same time, but with a focus on package delivery for individuals or small businesses.
What I'm worried about the most is package insurance. How is this usually done? Do I need to setup a policy with an insurance company? Or can I just mention in the ToS something like "we are not responsible for the condition of the received package"?
Any input on this or any other potential hurdles would be appreciated.
While I can't comment on the kind of insurance your business might need, in the case of UberRUSH, if a package gets crushed in transit, UberRUSH has insurance up to $250. If the package gets crushed due to our service, we will take care of it.
FedEx is not really focused on same day/same hour intra city delivery. Most of the shipping providers have an infrastructure around warehouses set in place. This means that the shipping providers picks up all packages and then brings them to a warehouse where they are sorted and then shipped out again. UberRush comes to the pick-up location and directly brings it to the recipient.
> FedEx is not really focused on same day/same hour intra city delivery.
Well, in that they have lots of other services, sure, but FedEx does have both long-distance (FedEx SameDay) and shorter-time-window local (FedEx SameDay City) same-day services.
The main difference would be that FedEx isn't subsidizing rates with investor money to fuel growth, so its more expensive.
Sure. I've been involved with a bunch of vendors who exhibit at conferences. Often there is an "oh shit" moment when you unbox the crates and find that the monitor you have is busted. You're missing an audio cable. You really need a 4' 2x4 to fix a collapsed table.
Doesn't really matter, but you could see a need for an "equipment and stuff" on demand in an hour type of service catering to these events.
Similarly, every wedding venue can have an "emergency" service for missing stuff ("Florist flaked? We can put petals to the metal and have them there in an hour!")
These are perhaps more extreme, but I'm sure there are any number of restaurants in your area that don't deliver, but might like to have that capability. One morning last week I went to my local bagel shop to find the manager loading dozens of boxes of bagels into her car (catering for the local school's Teacher Appreciation Day). There is insufficient demand for the bagel shop to have a full time delivery driver, but big catering orders UberRush might really fill a need for them.
The local delivery case is really where UberRUSH provides the most value. We also take pride in our developer tools and experience and invite you to check out our docs:
Oh man, oh man. Don't get me started on the utter mess that the UPS and FedEx APIs are. I've gone through the app certification process for both, as well as Stamps.com (USPS), and I think the only other project that rivals that mess is ADP (development took over a year, certification took another 6 months and 10s of thousands in fees.)
As an example, the developer document solely for obtaining shipment rates is 98 pages long.
> FedEx et all will deliver to my doorstep, but can they be here in an hour?
FedEx SameDay City Priority seems to guarantee delivery within 2 hours from package ready time within the shortest (0-15 mile) delivery range, and its available in a lot more cities than UberRUSH.
Competition with bike messengers in the case of same-day wet-signature document delivery. Very big demand among legal and financial firms within major cities.
"Tip: While couriers will come in store to pick up the delivery, the most successful users of UberRUSH conduct curbside handoffs. By eliminating the time required for your courier to park and find the handoff spot, you can have your deliveries arrive to your users as fast as possible!"
As this is a service intended for people with no existing logistics infrastructure, this seems to be firmly in line with the uber policy of reminding everyone why rules are created in the first place...
From the article: "An UberRUSH delivery typically involves interaction between three parties: the customer, the business, and Uber (courier). The diagram below outlines the interaction between these parties during the delivery lifecycle."
So the drivers are not a party to the transaction? Is Uber still trying to claim they are "independent contractors"?
That's a curious way to look at it. If you are a developer and need to deliver items to your customers or customers' customers, surely you'll need to pay someone to do that. Via the UberRUSH API, you can now integrate our delivery services to handle that, and yes, either you or your customer would need to pay for the delivery service.
The benefit of using the UberRUSH API is that you can take advantage of the elasticity of Uber's fleet to scale up and scale down delivery services on demand without needing to build up or manage your own couriers.
We think of it similar to how developers use AWS: developers could run their own server infrastructure but their costs would be much higher on a per-unit basis because they don't have the scale or purchasing power that Amazon has. Furthermore, running servers and dealing with amortization and depreciation probably isn't good for their businesses (unless their businesses are in scalable server hosting!).
We hope that developers use the UberRUSH API to lower the costs of running businesses that need to move physical goods in cities where we operate; we know full well the costs and challenges of setting up an elastic logistics network (it's our core business) and are passing on those capabilities and cost savings to third parties so they can focus on the value that they're providing, rather than merely on how to fulfill requests.
Thank you for providing the list. Its more open that I would have imagined. Do the current Uber imposed car requirements still apply? (I mean the year / type of car allowed).
It varies; if you drive with Uber, then you can choose to also deliver goods and products. Some driver-partners choose to only do deliveries for UberRUSH; some do both.
Here are the requirements to deliver for UberRUSH:
- Be at least 19 years old (21 years old in Canada)
- Be able to lift 50 lbs
- Have a driver’s license, insurance, and vehicle registration
Well, that's how it starts. Then you get Uber paying people with Vans, pickups, and vehicles capable of moving lots of stuff at once to move things from town to town. And so on until there are Uber commercial trucking drivers.
What do you mean by this? Is this a way for small business owners to get UberRUSH integrated without the need for a developer? They announced it as an API so I figured there had to be some manual integration. If there is manual integration required, this seems like a good fit for a consultant to come in and do it.
Correct. The UberRUSH API is for those businesses or developers that want more control over how they integrate UberRUSH into their business or customer experience. Prior to launching the API, UberRUSH was available for businesses through the console mentioned above without requiring any coding.
