Serve Robotics opens its 2,000-robot fleet to developers

By Elena Vasquez

Serve Robotics opened a public delivery API on November 11, 2026, giving developers and AI assistants access to a sidewalk delivery fleet of 2,000 robots.

The AV Delivery Developer Portal includes a sandbox where teams can test the full delivery flow against simulated robots without sending a physical machine onto a street.

Third-party delivery partners had been the only route to Serve’s robots before the portal. Outside applications can now initiate deliveries directly, rather than requiring an integration with a large delivery platform.

Serve reports hundreds of thousands of completed deliveries across more than 150 neighborhoods in 20 U.S. cities. The portal does not grant unrestricted access to that fleet; Serve requires approval before live dispatch.

For businesses, direct API access changes who controls the customer-facing workflow. They can connect an existing app to Serve, rather than route every request through a delivery intermediary.

That makes physical delivery a feature an outside team can design, while Serve still handles the street-level work.

The change matters because it shifts Serve from a partner-led delivery service toward a developer platform for physical fulfillment, while creating a software layer for AI assistants. Those assistants can pass pickup and drop-off details through the same API.

Four days earlier, on November 5, Serve launched Physical AI Services. The service opened the technology behind its robots to companies developing new types of robots. The delivery portal addresses a different layer: access to deliveries on Serve’s existing fleet.

Who can use Serve’s new delivery API?

The portal serves independent developers, businesses and AI assistants. An application supplies pickup and drop-off details, confirms the delivery and tracks the robot.

A developer can build around Serve’s logistics without operating robots or handling dispatch, route planning, navigation and supervision. Serve keeps those jobs. Outside teams own the software and customer experience.

The application can quote first and accept the returned price, or use the instant-jobs path when it always accepts the price. In either case, it supplies the addresses, confirms the order and presents tracking.

“You shouldn’t have to start a robotics company to build something useful with robots,” said Ali Kashani, Serve’s co-founder and CEO.

Kashani said people living and working in the neighborhoods served by its robots may have needs the company has not anticipated. His comment frames the API as a way to discover those uses. That approach does not require every outside team to build a robotics company.

The API can sit behind merchant apps, internal tools or assistant workflows. Serve presents those as examples, not commitments. For developers, the trade is straightforward: Serve supplies the robot network and operational controls, while the developer supplies the interface and the customer experience.

How does the API move a delivery from quote to drop-off?

The official Delivery API documentation describes three principal REST calls:

• Request a quote. The response includes an identifier, a fee and an estimated drop-off time.
• Create a job from an accepted quote.
• Poll the job until its status reads dropoff_complete.

The identifier links an accepted quote to its job. The polling call supplies a machine-readable completion signal, while the route endpoint provides a separate map display for the developer’s own interface.

Each quote expires after five minutes and can be used only once. An instant-jobs endpoint combines quoting and job creation for applications that always accept the price.

Developers can also retrieve a job’s planned route and display it on their own map. The application or AI assistant supplies pickup and drop-off details. It confirms the delivery and tracks the robot through the API.

The API exposes pricing, job creation and tracking, yet it does not expose the machinery that moves the robot along its route, because Serve still handles dispatch, routing, navigation and supervision.

What can developers test in the sandbox?

The sandbox runs the complete delivery lifecycle against simulated robots. Developers can follow a request through quoting, creation, tracking and completion without dispatching a physical vehicle.

The documentation lets builders force eight rejection conditions. They cover:

• Pickup locations a robot cannot traverse.
• Drop-off locations a robot cannot traverse.
• Excessive delivery distance.
• Requests outside operating hours.
• Unreachable pickup deadlines.
• Unreachable drop-off deadlines.
• Busy couriers.
• Internal errors.

Each simulated rejection gives software a concrete failure state to handle. The sandbox can therefore exercise both successful requests and exception handling before a real robot enters the workflow.

That lets builders test exception handling alongside successful deliveries. Sandbox access does not automatically authorize live deliveries. A successful simulated request does not grant permission for a physical robot.

The sandbox removes live-vehicle risk from the testing stage, but Serve deliberately retains a separate approval gate before any simulated request can become a live delivery.

When can an API request reach a live robot?

Real-robot dispatch requires Serve’s approval. Early-access invitations open one neighborhood at a time. Each request still depends on active service in that area.

Serve says robots dispatched through the API remain subject to its standard remote monitoring by trained supervisors. Each vehicle also carries safety systems built into the robot itself.

Route access does not make outside teams remote operators. They can display a planned path. Serve’s supervisors retain authority during the trip, and the robot’s built-in systems remain active.

Live deliveries must stay within active service areas and operating hours. Items must fit inside the robot. Its insulated compartment can hold up to four large pizza boxes, plus drinks and sides.

The approval process lets Serve extend access without surrendering control of dispatch, navigation or safety. Developers gain only the live service approved for covered neighborhoods, while Serve manages the robot fleet and its safety systems behind it throughout each trip.

What could developers build with the service?

Serve identifies these potential uses:

• Inter-office transport.
• Merchant deliveries to customers.
• Expanded local-business delivery.
• Delivery features inside existing apps.
• Personal errands.
• Tasks assigned to AI assistants.

In the illustrative assistant use case, a task comes with pickup and drop-off details. The assistant can then use the delivery status to track the assigned job.

Serve says these examples remain illustrative. Availability depends on location, operating hours and the item being sent. Every live request still runs through the same approval, neighborhood, cargo and operating controls.

Opening the API lets outsiders build software and customer experiences around Serve’s delivery network, while Serve keeps control of the robots, operating decisions and cargo limits.

For outside developers, the next milestone is live approval in additional neighborhoods, not another sandbox capability. Until then, teams can test the workflow but cannot turn a simulated order into a street delivery on their own. The rollout will turn on how quickly Serve closes that gap while keeping every trip within its safety and service controls.