Authentication

The Serve Delivery API accepts two credentials. Which one you use depends on what is making the call, not which endpoint you are hitting.

Both are accepted on partner-scoped endpoints, meaning everything under /v2/partners/{partner_id}/.

API key

Pass it on every request:

curl -X POST "https://api.sandbox.serverobotics.com/v2/partners/$PARTNER_ID/quotes" \
  -H "X-API-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d "$REQUEST"

Your Serve representative issues the key and your partner_id together. The two are bound: a key only authorizes calls under its own partner, so a 401 usually means they have been mixed up rather than that the key is invalid.

Your partner_id (it starts with ptnr_) is part of the base URL, https://api.sandbox.serverobotics.com/v2/partners/{partner_id}, not a parameter on each endpoint. In the API Reference, set it once in the base URL. Until you do, Try It shows the YOUR_PARTNER_ID placeholder.

Keys can be rotated and revoked via API. Rotation takes effect immediately and the previous key stops working on the next request, so roll it into your secret store before you rotate rather than after.

Serve Connect Token

curl -X POST "https://api.sandbox.serverobotics.com/v2/partners/$PARTNER_ID/jobs" \
  -H "Authorization: Bearer $SERVE_CONNECT_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$REQUEST"

Serve Connect Tokens are short-lived and refresh client-side. They are the right credential for a signed-in user acting in Serve Connect, and the wrong one for a backend integration. A server holding a refresh token to mint new tokens is doing more work than sending an API key.

Sandbox and production are separate

Sandbox is https://api.sandbox.serverobotics.com and production is https://api.prod.serverobotics.com. Keys work only on the environment that issued them. Sandbox partners get simulated robots and can force rejection paths with simulate_rejection; both are rejected in production. Ask your Serve representative when you are ready for production credentials.

What a failure looks like

Every error shares one shape:

{ "code": "something_went_wrong", "detail": "Description of what went wrong." }

A 401 is worth distinguishing from a 403 in your client: 401 means the credential is wrong, 403 means the credential is valid but does not own the resource, usually a partner_id that isn't yours.