FAQ
I want to integrate a new controller with Bifrost, where do I start?
We are glad to have you on board! Start with Getting Started, which walks you through the three-step onboarding flow: gathering your controller's .proto telemetry schema and firmware status in Pre-flight, submitting your Onboarding Request, and verifying access with the Validation Checklist.
How do I get an API key to interact with Bifrost APIs?
Bifrost does not issue static API keys. Instead, all authentication goes through AWS IAM roles (see Authenticating and Making API Requests). Using IAM roles eliminates the risk of leaked or unrotated static secrets, provides short-lived credentials that AWS refreshes automatically, and lets your workloads use a single identity across both HTTP APIs and the Kinesis telemetry stream with clear viewer, editor, and owner permissions.
I cannot access the Bifrost AWS account. How do I get access?
You shouldn't need direct access to a Bifrost AWS account! All interactions with Bifrost go through our exposed services (the MQTT server, the HTTP APIs, and the Kinesis telemetry stream) by assuming your business unit's IAM role. If you want to explore the underlying infrastructure or inspect resources directly, you can request StandardReadOnly access on any of the accounts listed in Accounts.
I made a mistake and created a device with the wrong IMEI, what do I do?
Because the IMEI is the device's unique identifier, it cannot be updated in place. A user or service in your business unit with the owner role should delete the mistaken device record, and you can then create a new device with the correct IMEI. See Permission Levels and Manufacturing.
Does Bifrost guarantee that telemetry messages arrive in chronological order?
No. Downstream consumers cannot assume that the order in which messages are received from the telemetry stream or Data API matches the order in which the controller recorded them or the IoT Gateway sent them. AWS IoT Core does not guarantee message ordering when forwarding MQTT payloads, and Amazon Kinesis Data Streams only preserves the cloud arrival order in which records reached the stream (which is especially noticeable when an offline device reconnects and flushes buffered data).
To handle out-of-order delivery, the timestamp data contract defining the real event time must be guaranteed between the application level and the IoT Gateway, and downstream consumers should sort or evaluate state transitions using that payload timestamp rather than the cloud arrival time.
Why did older telemetry stay on the previous destination?
A change of business unit or environment applies to messages after the change. Data already delivered stays where it was written. See Where data lands.
The device is registered. Why is nothing arriving?
Until first-boot provisioning succeeds, the device cannot publish. Provisioning does not assign a business unit. Data also has no destination for your unit until the business unit is set. See Commissioning.