Skip to main content
This documents the external Shubble API (api-shuttles.rpi.edu), not Meridian core REST. It lives under Mobile because shuttle surfaces ship primarily in campus mobile experiences.

Base URL

Overview

The Shubble API provides real-time shuttle tracking data for Rensselaer Polytechnic Institute (RPI). All endpoints return JSON data and do not require authentication for GET requests.

Response Headers

Some endpoints include helpful timing headers:
  • X-Server-Time: Current server time in ISO format
  • X-Oldest-Data-Time: Timestamp of the oldest data point in the response
  • X-Data-Age-Seconds: Age of the oldest data point in seconds

Endpoints

1. GET /api/locations

Returns the latest location for each vehicle currently inside the geofence. Response: Object keyed by vehicle ID, containing location data for each active shuttle. Example Request:
Example Response:
Response Fields:
  • name (string): Vehicle name/number
  • latitude (number): GPS latitude coordinate
  • longitude (number): GPS longitude coordinate
  • timestamp (string): ISO 8601 timestamp of the location reading
  • heading_degrees (number): Vehicle heading in degrees (0-360)
  • speed_mph (number): Vehicle speed in miles per hour
  • is_ecu_speed (boolean): Whether speed is from ECU or GPS
  • formatted_location (string): Human-readable address
  • address_id (string): Samsara address ID
  • address_name (string): Name of the location/address
  • license_plate (string): Vehicle license plate
  • vin (string): Vehicle identification number
  • asset_type (string): Type of asset (typically “vehicle”)
  • gateway_model (string): Gateway device model
  • gateway_serial (string): Gateway device serial number
  • driver (object|null): Current driver information
    • id (string): Driver ID
    • name (string): Driver name
Caching: 15-300 seconds (soft/hard TTL)

2. GET /api/velocities

Returns predicted velocity and route matching data for each vehicle currently inside the geofence. Response: Object keyed by vehicle ID, containing velocity predictions and route information. Example Request:
Example Response:
Response Fields:
  • speed_kmh (number|null): Predicted speed in kilometers per hour
  • timestamp (string): ISO 8601 timestamp of the velocity reading
  • route_name (string|null): Name of the matched route (e.g., “NORTH”, “WEST”) or null if not matched
  • polyline_index (number|null): Index into the route polyline array
  • is_at_stop (boolean): Whether the vehicle is currently at a stop
  • current_stop (string|null): Name of the current stop if is_at_stop is true
Caching: 15-300 seconds (soft/hard TTL)

3. GET /api/etas

Returns ETA (Estimated Time of Arrival) information for each vehicle currently inside the geofence. Response: Object keyed by vehicle ID, containing predicted arrival times for each stop on the route. Example Request:
Example Response:
Response Fields:
  • stop_times (object): Object keyed by stop name, containing ISO 8601 timestamps for predicted arrival times
  • timestamp (string): ISO 8601 timestamp when the ETA predictions were calculated
Caching: 15-300 seconds (soft/hard TTL)

4. GET /api/routes

Returns route definitions including polylines, stops, and colors. Response: Object containing route definitions for all shuttle routes. Example Request:
Example Response (truncated):
Response Fields:
  • COLOR (string): Hex color code for the route (e.g., “#FF0000” for red)
  • STOPS (array): List of stop identifiers in order
  • POLYLINE_STOPS (array): List of stops including ghost stops for polyline rendering
  • [STOP_NAME] (object): Stop definition objects containing:
    • COORDINATES (array): [latitude, longitude]
    • OFFSET (number): Offset into the polyline array
    • NAME (string): Human-readable stop name
  • ROUTES (object): Route variants keyed by route identifier, containing:
    • POLYLINE (array): Array of [latitude, longitude] coordinate pairs
Caching: No caching (serves static file)

5. GET /api/schedule

Returns the shuttle schedule organized by day and route. Response: Object containing schedule data organized by day type and route. Example Request:
Example Response (truncated):
Response Structure:
  • Day names map to day type strings (“weekday”, “saturday”, “sunday”)
  • Day type objects contain route schedules keyed by route name
  • Each route schedule is an array of [time, route_name] pairs
Caching: No caching (serves static file)

6. GET /api/today

Returns all location data and geofence events for today (campus timezone). Response: Object keyed by vehicle ID, containing historical location data and geofence entry/exit times. Example Request:
Example Response (truncated):
Response Fields:
  • entry (string|null): ISO 8601 timestamp of first geofence entry today, or null if not entered
  • exit (string|null): ISO 8601 timestamp of geofence exit today, or null if still in geofence
  • data (array): Array of location readings throughout the day, each containing:
    • latitude (number): GPS latitude
    • longitude (number): GPS longitude
    • timestamp (string): ISO 8601 timestamp
    • speed_mph (number): Speed in miles per hour
    • heading_degrees (number): Heading in degrees
    • address_id (string): Samsara address ID
Note: “Today” is calculated based on campus timezone (America/New_York), not UTC. Caching: No caching

7. GET /api/aggregated-schedule

Returns aggregated schedule data. Response: Aggregated schedule information (may return 404 if file not found). Status: May not be available on all deployments.

8. GET /api/matched-schedules

Returns matched schedules with vehicle-to-stop assignments. Response: Object containing matched schedule information. Example Request:
Example Response:
Response Fields:
  • status (string): “success” or “error”
  • matchedSchedules (object): Matched schedule data (may be empty)
  • source (string): “computed” or “recomputed”
Caching: 3600-86400 seconds (1 hour to 1 day)

9. POST /api/webhook

Webhook endpoint for receiving geofence events from Samsara. Authentication: Requires Samsara webhook signature verification. Request Headers:
  • X-Samsara-Timestamp: Timestamp of the webhook
  • X-Samsara-Signature: HMAC signature for verification
Request Body: JSON payload containing geofence event data. Response:
Note: This endpoint is intended for Samsara webhook integration and requires proper authentication. Not typically used by frontend applications.

Error Responses

All endpoints may return standard HTTP error codes:
  • 400 Bad Request: Invalid request parameters
  • 404 Not Found: Resource not found
  • 405 Method Not Allowed: HTTP method not supported
  • 500 Internal Server Error: Server error
Error responses follow this format:

Rate Limiting & Caching

  • Most endpoints are cached with Redis (15-300 second TTLs)
  • No explicit rate limiting is enforced, but excessive requests may be throttled
  • Cache headers are not currently exposed in responses

Frontend Integration Examples

JavaScript/TypeScript Example

React Hook Example


Notes for Frontend Developers

  1. Vehicle IDs: Vehicle IDs are large integers (e.g., 281474977371235). Use them as keys in client-side maps keyed by vehicle id.
  2. Timestamps: All timestamps are in ISO 8601 format with UTC timezone (+00:00). Convert to local time as needed.
  3. Route Matching: Use /api/velocities to get route matching data. The route_name will be null if the vehicle is not close enough to any route (< 0.050 distance threshold).
  4. Empty Responses: If no vehicles are in the geofence, endpoints return empty objects {}.
  5. Data Freshness: Check the X-Data-Age-Seconds header on /api/locations to determine how fresh the data is.
  6. CORS: The API may have CORS restrictions. If building a frontend on a different domain, you may need to configure CORS or use a proxy.
  7. Polling Frequency: Recommended polling interval is 15-30 seconds to balance freshness with server load.

Support

Shubble is operated for RPI campus mobility; Meridian consumes this HTTP API from mobile and related clients. For Meridian integration or documentation fixes, work in the Meridian repository (and sibling checkouts such as Events-Backend if your change spans the events module). For Shubble service outages, contract, or API contract changes, use the internal RPI / Study Compass operations path for that integration—not this developer docs site.