Sandbox

The Autolane Sandbox is a fully isolated environment for integration development. Same /dd/v1/* API surface as production, same request/response shapes, same webhooks. The difference is that every delivery is fulfilled by a synthetic autonomous vehicle you control from the Autolane Portal instead of a real autonomous vehicle dispatched to a customer.

Use the sandbox to:

• Build your integration end-to-end before any real money or real autonomous vehicle dispatch is involved.
• Drive a delivery through every lifecycle state at your own pace, on demand, from the portal UI.
• Test webhook handlers against real Autolane-signed payloads with the canonical retry behavior.
• Reproduce failure modes (out of service area, customer opted out, geocode failure) deterministically.

Getting started

Base URL

https://api-sandbox.goautolane.com/dd/v1/*

The path surface is identical to production. Only the host changes.

Creating a sandbox API key

1. Log in to the Autolane Portal.
2. Switch to dev mode (toggle in the top navigation).
3. Open Integrations > API Keys in the sidebar.
4. Click + Create API Key.
5. Give the key a name (e.g., “Sandbox dev”), select the permissions your integration needs (deliveries:read, deliveries:write, webhooks:manage), and click Create.
6. Copy the key. It is only shown once.

Sandbox keys can only be used against api-sandbox.goautolane.com. Using a sandbox key against the production host (or vice versa) returns 403 WRONG_ENV_KEY.

Your x-retailer-id

Use the site UUID shown in the Autolane Portal while it is in dev mode. The portal lists your organization’s sites separately for each environment; the “dev mode” badge confirms which environment you’re currently configuring. When you promote to production, check the production listing for the site you want to call against and use that UUID with your production key.

Synthetic actors

Every sandbox retailer is pre-provisioned with one synthetic vehicle and one synthetic supervisor driver, both flagged with is_synthetic = true server-side. When you create a delivery in the sandbox:

• The pickup is eagerly assigned to your synthetic vehicle/driver pair at create time (in production, pickups sit in the driver queue until they’re claimed for dispatch).
• The pickup is created in SCHEDULED status with is_autonomous = true.
• The order is tagged with admin_test_order_meta.driver_mode = 'synthetic' so no production dispatch path can ever reach it.

You will not see any of this assignment metadata in the public API response. The order behaves like a regular Direct Delivery order from your code’s perspective. The difference shows up in the lifecycle: you advance it.

Quoting and creating a delivery

The two-step quote-then-create flow is identical to production. A normal happy-path request looks the same:

$
curl -X POST https://api-sandbox.goautolane.com/dd/v1/deliveries/quote \
>
  -H "Authorization: Bearer YOUR_SANDBOX_API_KEY" \
>
  -H "x-retailer-id: a1b2c3d4-e5f6-7890-1234-567890abcdef" \
>
  -H "Content-Type: application/json" \
>
  -d '{
>
    "external_delivery_id": "SANDBOX-001",
>
    "customer": { "phone": "+15551234567" },
>
    "delivery_address": {
>
      "street": "123 Main St",
>
      "city": "Austin",
>
      "state": "TX",
>
      "zip": "78701"
>
    },
>
    "ready_by": "YOUR_FUTURE_ISO8601_UTC_TIMESTAMP",
>
    "order_items": [{ "name": "Latte", "quantity": 1 }]
>
  }'

$
curl -X POST https://api-sandbox.goautolane.com/dd/v1/deliveries \
>
  -H "Authorization: Bearer YOUR_SANDBOX_API_KEY" \
>
  -H "x-retailer-id: a1b2c3d4-e5f6-7890-1234-567890abcdef" \
>
  -H "Content-Type: application/json" \
>
  -d '{ "external_delivery_id": "SANDBOX-001" }'

Simulating failure modes

Every unavailable_reason the production API can return is reachable in the sandbox by varying request input. No special flag, no admin lever; just the same logic.

Driving a delivery through the lifecycle

Once a sandbox delivery is created, you advance it through pickup states from the Autolane Portal. Open the delivery in the portal’s Test Deliveries view, then use the Advance button to step the synthetic pickup forward one state at a time:

SCHEDULED → ASSIGNED → EN_ROUTE_TO_STORE → ARRIVED_AT_STORE →
  WAITING_FOR_LOAD → LOADED → EN_ROUTE_TO_CUSTOMER →
  ARRIVED_AT_CUSTOMER → COMPLETED

Each click advances exactly one state and fires the corresponding pickup_status.changed webhook at your registered URL (if you’ve subscribed to the event). You can also cancel from the portal at any non-terminal state, which fires pickup_status.changed with status: "CANCELLED".

The delivery’s top-level status on GET /dd/v1/deliveries/{external_delivery_id} advances in lockstep — the GET response and the webhook stream always agree on the same lifecycle value.

There is no public API endpoint for advancing a sandbox pickup. The advance flow is intentionally portal-only so that integrations exercise their webhook handlers, not a server-driven simulation loop.

Testing webhooks

Webhook delivery in sandbox is the same code path as production: same X-Autolane-Signature HMAC-SHA256 over the body, same X-Autolane-Delivery-Id UUID stable across retries, same 5-attempt 30-second-base exponential backoff, same 50-consecutive-failure auto-disable + email notification.

Recommended workflow:

1. Register your sandbox webhook against your dev environment (an ngrok or cloudflared tunnel to localhost is fine; the URL just needs to be HTTPS).
2. Subscribe to pickup_status.changed (and pickup.vehicle_location.changed if you’re building a live-map UI).
3. Create a delivery in sandbox.
4. Advance the pickup from the portal one state at a time, verifying that each pickup_status.changed arrives at your endpoint, your signature verification passes, and your idempotency logic handles re-delivered events correctly.

The portal’s Test Deliveries view also shows a per-delivery event log. Each row is one outbound webhook attempt (HTTP status, response body, latency, error message if any) so you can correlate what we sent against what your endpoint received.

Differences from production

Promotion to production

Promotion to production includes completing all 7 of the onboarding steps in the portal, then clicking the Request Production Access button. Our onboarding team will review your integration within 24 hours.

Once approved, switch your integration over:

1. Create a production API key in the portal (switch the dev-mode toggle off, then Integrations > API Keys > + Create API Key). Production keys carry the env:production marker and only work against https://api.goautolane.com.
2. Update your production environment with the new key. Sandbox keys won’t work against the production host (403 WRONG_ENV_KEY).
3. Re-register your production webhook against your production webhook URL. Sandbox and production webhook subscriptions are separate; registering one does not create the other. Use a different signing secret per environment.
4. Walk through every webhook handler at least once against the production host by running a low-risk first delivery through. The retry and signature behavior is identical to sandbox, but a real autonomous vehicle (or a supervisor on supervisor-equipped sites) is now involved.
5. Confirm x-retailer-id maps to the production site UUID. The portal’s production view and dev-mode view list sites separately; do not reuse a sandbox UUID against the production host. Pull the UUID from the production listing.

If anything looks different between sandbox and production behavior, please report it; the contract is meant to be byte-identical except for the items in the table above.