RAD-enhanced
Overview
The RAD (RapidSOS Additional Data) Enhanced API provides a RESTful interface for querying additional data from various sources. Data from these sources is queried by phone number or RapidSOS Alert ID. It can also be queried by unique identifiers associated with the owner of the data, such as their phone number or MedicAlert ID.
IMPORTANT: It is strongly recommended that when integrating this API, fields should not be hard-coded. This is because it assumes that information which should be flexible is actually fixed and unchanging. It is best practice to develop a UI renderer based on our auto-rendering schema language to allow for generating UI components native to your software for any data fields that might be added, updated, etc. for any source.
Data Access
All available sources of additional data provided to RapidSOS that your integration has been approved to receive will be made available using the RAD Enhanced endpoint.
Data Sources
The available data sources allow a pre-defined "display" schema for data received by RapidSOS Portal. This dynamic schema allows it to automatically infer how these elements should be rendered.
Example Data Sources
- 911 Inform
- 911Secure
- Cove
- Emergency Health Profile
- MedicAlert
- SiriusXM
- Uber
Rendering Schema and Data
The schema is defined per data source and dictates field ordering, labeling, formatting, etc. allowing for the automatic processing and rendering of the many new data types without the need for new UI development work every time a new data set is added.
Auto Generate Components from Data and Schema : The library takes a data object and a display schema as its input and return UI components representing those data points as defined by the display schema.
Text, Link, and Timestamp Support
The library can support rendering data as either text, a URL link, a human readable timestamp, hidden, dates and images. The criteria for rendering based on the schema is as follows:
Sample web-url:
- type: string
- format: web-url
- Recommended UI Element Type: clickable link (optional)
Sample timestamp:
- type: integer
- format: timestamp
- UI: ISO80 Datestring
Sample plain text:
- type: integer, number, or string
- format: None specified. This can optionally be text.
- UI: text
Object Rendering
The library supports rendering fields with nested objects. The display schema defines these fields as an object and defines a display schema for each nested field within it. These nested fields cannot be objects or arrays. They must be strings or numbers.
Sample nested object data and display schema:
Data
Display Schema
Array Rendering
The library can support rendering a field whose value is a list of values. These values can be any strings, numbers, or objects.
Generated UI components should provide a visual indicator separating each element of the list from one another.
Sample array data and display schema:
Ordered Components
The display schema defines a propertiesOrder attribute that defines the expected order in which each property is meant to be rendered.
Your renderer should use this ordered list defined in the attribute to determine the order in which to render all properties within any object in the schema.
Example Schema
The following is an illustrative example of a fictitious ABC Corporation schema defining all required top-level attributes as well as at least one field of each of the types supported:
Additional Considerations
The following considerations should be reviewed before implementing the RapidSOS Additional Data (RAD-E) solution:
- Uber data: we do not receive differentiation regarding if the driver or rider triggered the alarm
- There is not always additional data available for a call
- Regarding data retention and privacy, the data we provide is all voluntarily
- The partner must have the caller ID to query the API
- Additional Data is available for 10 minutes from the first push by the data partner
- Partners should make use of key error handling and utilize loops through the API response