AtlasCare supports automated trip-option checks (availability + estimated pricing together) and online trip-request submission through this API. It's documentation for AI agents, facility systems, and other integrations — human customers should use Check Availability & Pricing, which calls this same API.
/api/v1/openapi.json (mirrored at /.well-known/openapi.json for tooling that checks there first) — point an agent framework at either URL instead of having it parse this page.AtlasCare Transport provides private, non-emergency medical transportation for adults — wheelchair-accessible and ambulatory — including hospital discharges, medical appointments, dialysis and treatment transport, and facility transfers. Every trip includes a private vehicle and driver, assisted door-to-door service, and one family member or caregiver at no extra charge. Wait & Return service keeps the vehicle and driver dedicated to a passenger's appointment.
McMinnville, Oregon and Yamhill County, with regional trips to the greater Portland and Salem areas. Requests outside this area are still accepted — they're routed to manual review rather than rejected.
v1 — base path /api/v1/. Breaking changes will use a new version prefix; this document always describes the current v1 contract.
None required for the actions below in V1 — they are read-only or create a non-binding trip request (see Important: Request vs. Booking). Endpoints are protected by bot-abuse protection at the network level plus a per-IP application-level rate limit (see Rate Limiting & Fair Use below), not by API keys.
REQUEST_TRIP) never creates a confirmed, paid reservation by itself. It enters AtlasCare's normal staff review workflow. There is no public, unauthenticated CONFIRM_BOOKING action.scheduled_return time falls within operating hours, or account for how long a vehicle is committed on a wait_and_return trip. A round trip can be priced and marked available even if the return leg would fall outside normal hours — AtlasCare's staff review before confirmation is what catches this today. Do not describe round-trip availability as fully verified end-to-end.POST /api/v1/availability
Determines whether AtlasCare appears able to serve a requested pickup window. Does not calculate a price.
{
"pickup_datetime": "2026-09-15T08:00:00-07:00"
}
{
"status": "available",
"label": "Available",
"message": "AtlasCare currently has capacity matching this request.",
"requested_datetime": "2026-09-15T08:00:00-07:00"
}
POST /api/v1/quote
Calculates pricing only (no availability check). Returns a signed, time-limited quote token that can be passed to REQUEST_TRIP so the confirmed price is never recalculated from a different, possibly-changed rate.
{
"pickup_address": { "formatted": "2700 NW Stewart Pkwy, McMinnville, OR" },
"destination_address": { "formatted": "3181 SW Sam Jackson Park Rd, Portland, OR" },
"pickup_datetime": "2026-09-15T08:00:00-07:00",
"mobility_type": "wheelchair",
"trip_type": "round_trip",
"return_type": "wait_and_return",
"broda_required": false
}
{
"id": "ATQ-260915-A7K4",
"token": "<opaque signed token>",
"status": "estimated",
"total": 330,
"currency": "USD",
"included_wait_minutes": 60,
"additional_wait_rate": { "amount": 20, "minutes": 15 },
"expires_at": "2026-09-18T08:00:00.000Z"
}
POST /api/v1/trip-options
Calls availability and pricing together and returns one customer-facing result — the same endpoint AtlasCare's own Check Availability & Pricing page uses. Same request shape as /api/v1/quote above.
request_trip_url is prefilled with every field from your request plus the quote id/token, so a person you hand this link to lands on the wizard with their trip already filled in instead of retyping it.
{
"serviceable": true,
"availability": { "status": "available", "label": "Available", "message": "..." },
"quote": { "id": "ATQ-260915-A7K4", "token": "...", "status": "estimated", "total": 330, "currency": "USD", "included_wait_minutes": 60 },
"request_trip_url": "/availability-pricing?quoteId=ATQ-260915-A7K4"eToken=...&pickupAddress=2700+NW+Stewart+Pkwy%2C+McMinnville%2C+OR&..."
}
POST /api/v1/trip-requests
Submits a trip request into AtlasCare's staff review workflow. Include the quote_token from step 2 or 3 so the price shown to your user is the price AtlasCare reviews — a request without a token, or with an expired/invalid one, is priced fresh, server-side, at submission time rather than rejected. Support an Idempotency-Key header to safely retry; a retried key returns { "ok": true, "duplicate": true } instead of creating a second request.
source is required and must be one of: web_wizard, ai_agent, api_partner, facility_portal, phone_agent, staff. It costs nothing to send and gives AtlasCare a clean way to see, in the same notification email staff already read, whether a request came from a person or from something acting on a person's behalf — use ai_agent if that's you.
Required inputs: contact (first/last name and phone or email), pickup_address, destination_address, pickup_datetime (ISO 8601, future, see Date & Time Format below), mobility_type, and trip_type. return_type is required for a complete round-trip evaluation but its absence does not block submission — see Missing or Incomplete Inputs below.
Supported return arrangements (return_type, required when trip_type is round_trip): wait_and_return (vehicle and driver wait at the appointment), scheduled_return (a separate pickup at a specific later time — send it in scheduled_return_time), will_call (passenger calls when ready; return timing isn't known in advance). None of these are validated against operating hours automatically — see the return-trip feasibility limitation above.
Authorization: AtlasCare does not currently gate standard trip-request submission behind an explicit authorization check — the source and requester fields identify who is submitting, and staff review every request before confirming. The one place an explicit authorization confirmation is required is a recurring-transportation request, where the wizard requires a checked attestation ("I confirm that I am authorized to request this recurring transportation...") before it will submit.
Booking boundaries: a successful response here means AtlasCare received and will review the request — never that transportation is booked. There is no endpoint that returns a confirmed reservation synchronously.
Example — synthetic data, not a real customer or request:
{
"contact": { "first_name": "Jordan", "last_name": "Lee", "phone": "+15035551234", "email": "[email protected]" },
"pickup_address": { "formatted": "2700 NW Stewart Pkwy, McMinnville, OR" },
"destination_address": { "formatted": "3181 SW Sam Jackson Park Rd, Portland, OR" },
"pickup_datetime": "2026-09-15T08:00:00-07:00",
"mobility_type": "wheelchair",
"trip_type": "round_trip",
"return_type": "wait_and_return",
"quote_token": "<token from /api/v1/quote or /api/v1/trip-options>",
"requester_type": "individual",
"source": "ai_agent"
}
{
"ok": true,
"request_id": "ATR-2026-482913",
"status": "received",
"quote_status": "estimated",
"availability_status": "available",
"message": "AtlasCare received this trip request. Submitting this request does not create a confirmed reservation...",
"status_url": "/api/v1/trip-requests/ATR-2026-482913/status"
}
GET /api/v1/trip-requests/{request_id}/status
Returns whatever status AtlasCare has recorded for a request. In V1 this is best-effort — most requests are still followed up on by phone or email.
GET /api/v1/config
The same posted pricing tiers, Wait & Return rates, and equipment charges shown on the website — safe to read directly instead of hard-coding AtlasCare's rates into your own system.
Send pickup_datetime (and scheduled_return_time, when used) as ISO 8601 with an explicit UTC offset, e.g. 2026-09-15T08:00:00-07:00. AtlasCare's service area and operating hours are defined in the America/Los_Angeles time zone; include the correct offset for that zone (-07:00 during Pacific Daylight Time, -08:00 during Pacific Standard Time) rather than assuming UTC.
A request to /api/v1/trip-options or /api/v1/trip-requests that is missing a required field (pickup_address, destination_address, pickup_datetime, mobility_type, or trip_type) is rejected with a 400 before any availability or pricing check runs:
{
"ok": false,
"error": "This trip request is missing required details: pickup_address is required. mobility_type must be one of: wheelchair, ambulatory, not_sure.",
"reason_code": "VALIDATION_FAILED"
}
The error string always spells out exactly which fields are missing or invalid — a caller (human or agent) can ask for those specific details and resubmit rather than guessing. return_type is the one exception: a round trip submitted without it is not rejected — it is priced with quote.status: "manual_review" so AtlasCare can confirm the return arrangement before finalizing.
| HTTP status | reason_code | Meaning |
|---|---|---|
| 400 | VALIDATION_FAILED | One or more required fields are missing or malformed; error lists which. |
| 400 | MISSING_FIELD | A single required field (e.g. pickup_datetime on /api/v1/availability) was not sent. |
| 400 | INVALID_DATETIME | pickup_datetime could not be parsed as ISO 8601. |
| 400 | PAST_DATETIME | The requested pickup date/time is in the past. |
| 413 | PAYLOAD_TOO_LARGE | Request body exceeded the size limit. |
| 429 | RATE_LIMITED | Per-IP rate limit exceeded — see Rate Limiting & Fair Use; back off for the seconds given in Retry-After. |
| 500 | — | An unexpected server error. On /api/v1/availability and /api/v1/trip-options, an internal failure in the availability check itself does not surface as a 500 or as unavailable — it degrades to a 200 response with status: "manual_review", so a transient technical failure is never presented as a confirmed lack of availability. |
| Status | Meaning |
|---|---|
available | Capacity currently appears open for this window. |
limited | Capacity may be available; AtlasCare will confirm the best pickup time. |
manual_review | Needs a quick scheduling review — not a failure state. |
unavailable | Not available at the requested time; try another time or submit for review. |
| Status | Meaning |
|---|---|
estimated | Calculated from AtlasCare's standard posted pricing rules. |
manual_review | One or more trip details need a human to confirm pricing (e.g. special equipment, unusual mileage, an incomplete return arrangement). Not a failure — still a valid, expected outcome. |
confirmed | Reserved for a future state once AtlasCare has explicitly confirmed a price with the customer. |
expired | The quote token's validity window has passed; request a new quote. |
These endpoints sit behind Cloudflare's network-level protections, plus a per-IP application-level limit with a numeric, machine-readable contract so an integration can self-throttle predictably instead of guessing:
| Bucket | Endpoints | Limit |
|---|---|---|
| Lookup | /api/v1/availability, /api/v1/quote, /api/v1/trip-options | 30 requests / 60s per IP |
| Submit | /api/v1/trip-requests | 10 requests / 60s per IP |
| Read | /api/v1/config, /api/v1/openapi.json, /api/v1/trip-requests/{id}/status | 60 requests / 60s per IP |
Every response from these endpoints carries X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset (seconds until the window resets) — check these instead of waiting to get cut off. Exceeding the limit gets a 429 with a Retry-After header (seconds to wait) and reason_code: RATE_LIMITED; back off for that long and retry. These numbers are also published live at /api/v1/config under rate_limits, so an integration can read the current limits instead of hard-coding them. Please also cache /api/v1/config and /api/v1/openapi.json (they change rarely) rather than relying on the rate limit alone.
For an integration that wants a short, machine-readable summary rather than parsing this page or the full OpenAPI document, AtlasCare publishes a custom /developers/capabilities.json — the AtlasCare capability manifest. It is not a universal discovery standard; it's a small AtlasCare-specific pointer to the same OpenAPI operations documented above, plus the plain-language limitations already described on this page.