CredentialsAndSchedulesV1
Manage user credentials and user schedules data on device.
Trait Type: Bulk Data
CredentialsAndSchedules data files
As this is a bulk data trait, interactions will require passing data in separate files rather than as payloads in the API requests and events. The data files passed to Yonomi Platform for writing data to the device as well as files passed from Yonomi Platform for reporting state of the device will have the following schema.
{
"credentials": [],
"schedules": []
}The “credentials” array may be left empty if the device is not to have any authorized credentials. Otherwise, this array should be populated with credential objects (See the “Defining CredentialsAndSchedules data objects” page).
The “schedules” array may be populated with Always Active, Temporary, and/or Recurring schedule type objects (See the “Defining CredentialsAndSchedules data objects” page). Any scheduleIds referenced by a credential object under the “credentials” array MUST have an associated schedule object under the “schedules” array.
When writing data to the device, data files must include ALL credential and schedule objects desired to be on the device (rather than just the objects to be updated) as sending new data will overwrite existing databases on the device.
Action Mutations
Note: See Overview: Device Action Lifecycle for more information on action flows
CredentialsAndSchedulesV1RequestCredentialsAndSchedulesURL action
Requests uploadUrl to allow writing a new CredentialsAndSchedules data to a device. Upon getting the URL, users must make a PUT request to that URL with data structure as defined in the "CredentialsAndSchedules data files" section on this page. Uploading the data will result in Asynchronous processing of the data file and uploading to the device. Any error or success responses on the action after uploading the data file will be surfaced as DEVICE_ACTION_UPDATED events.
Mutation Inputs
Input Name | Description | Data Type | Nullable |
deviceId | uuid of the device to which mutation should apply | ID! | false |
GQL Examples
Request Example
mutation CredentialsAndSchedulesV1RequestCredentialsAndSchedulesURL {
CredentialsAndSchedulesV1RequestCredentialsAndSchedulesURL(
deviceId: "9a8f6104-6c50-476e-90ee-16b9a2dafc8d"
) {
deviceId
actionId
uploadUrl
uploadUrlExpiresAt
}
}Response Example
{
"data": {
"CredentialsAndSchedulesV1RequestCredentialsAndSchedulesURL": {
"deviceId": "9a8f6104-6c50-476e-90ee-16b9a2dafc8d",
"actionId": "7eb3629a-a1c3-49f0-89b6-2831d500ac68",
"uploadUrl": "https://fakefileurl.com",
"uploadUrlExpiresAt": "2025-04-25T15:46:18.181Z"
}
}
}Reported States
Note: See Overview: Device Reported State for more information on reported state flows.
State Definitions
downloadUrl state
Url where data file containing all user credentials and user schedules data reported from device (schema as defined in the "CredentialsAndSchedules data files" section on this page). File includes entire dataset, not just the changes since last report.
Data Type: URL
downloadUrlExpiresAt state
timestamp when the downloadUrl is set to expire.
Data Type: string (Value formatted as an ISO 8601 UTC dateTime)
Device State Query GQL Examples
Request Example
query Device {
device(deviceId: "9a8f6104-6c50-476e-90ee-16b9a2dafc8d") {
id
traits {
... on CredentialsAndSchedulesV1DeviceTrait {
name
state {
downloadUrl {
reported {
value
}
}
downloadUrlExpiresAt {
reported {
value
}
}
}
}
}
}
}
Response Example
{
"data": {
"device": {
"id": "9a8f6104-6c50-476e-90ee-16b9a2dafc8d",
"traits": [
{
"name": "CredentialsAndSchedulesV1",
"state": {
"downloadUrl": {
"reported": {
"value": "https://fakefileurl.com"
}
},
"downloadUrlExpiresAt": {
"reported": {
"value": "2025-04-25T15:56:28.513Z"
}
}
}
}
]
}
}
}
What made this section unhelpful for you?
On this page
- CredentialsAndSchedulesV1