Serve Robotics Opens Delivery API to Developers and AI Agents

By Daniel Okafor

Serve Robotics launched its AV Delivery Developer Portal on November 11, 2026, giving independent developers, businesses and AI assistants a public API for requesting deliveries from its 2,000-robot sidewalk fleet. A built-in sandbox lets users test the workflow without dispatching a physical robot.

Serve says the portal separates access to delivery software from authority over fleet operations. Outside applications can now initiate jobs directly instead of requiring an integration with a large delivery platform. Developers can build the application and customer experience, while Serve retains dispatch, routing, navigation and supervision.

“You shouldn’t have to start a robotics company to build something useful with robots,” said Ali Kashani, Serve’s co-founder and CEO. He said people living and working in the neighborhoods served by its robots may have needs the company has not anticipated.

Serve says fleet access was available only through third-party delivery partners before the launch. The company reports hundreds of thousands of completed deliveries across more than 150 neighborhoods in 20 U.S. cities. The portal adds a direct software layer to an operating service.

What changed on November 11?

Serve launched Physical AI Services on November 5, opening the technology behind its robots to companies developing new types of robots. The November 11 Developer Portal addresses a different layer: access to deliveries on Serve’s existing fleet.

How does the delivery API work?

According to Serve’s official Delivery API documentation, the workflow rests on three principal REST calls:

• Request a quote. The response supplies an identifier, fee and estimated drop-off time. Each quote expires after five minutes and can be used only once.
• Create a job from an accepted quote.
• Poll the job until its status becomes dropoff_complete.

The 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, confirms the delivery and tracks the robot. Serve retains responsibility for dispatch, routing, navigation and supervision. Developers can integrate physical delivery without operating robots themselves.

What can the sandbox test?

According to Serve, the sandbox runs the complete delivery lifecycle against simulated robots. It does not dispatch a physical vehicle, so developers can test exception handling alongside successful deliveries.

Developers can force eight rejection conditions:

• 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.

Sandbox access does not automatically authorize live deliveries. Real-robot dispatch requires Serve’s approval, with early-access invitations opening one neighborhood at a time. Even robots dispatched through the API remain subject to Serve’s standard remote monitoring by trained supervisors and the safety systems built into each vehicle.

What are the delivery limits and uses?

Serve allows live API deliveries only within active service areas and operating hours, and its cargo must fit inside an insulated compartment holding up to four large pizza boxes plus drinks and sides.

Serve identifies inter-office transport, merchant deliveries to customers, expanded local-business delivery and delivery features inside existing apps as potential uses. Its examples also include personal errands and tasks assigned to AI assistants. Serve cautions that the examples are illustrative and availability depends on location, operating hours and the item being sent.

Serve is opening access to its robots without giving up operational control. Outside parties can build the software and customer experience, while live deliveries remain gated by Serve’s approval, neighborhood coverage, service hours and cargo limits.

The next test is whether Serve expands beyond one-neighborhood early access while retaining those approval, service-hour and cargo controls. Until then, the practical limit on API adoption remains fleet coverage and Serve’s approval, not developers’ ability to write the integration.