FAQs¶
Click on each question to see the answer
General¶
What is an API?
Answer: API stands for Application Programming Interface. An API allows developers to connect their application to another application. Our API enables you to connect your application to our products.
How can I contact GE Appliances regarding the APIs?
Answer: For information regarding the developer portal or our APIs, please use this contact form.
What brands does this API support?
Answer: GE Appliances maintains a house of brands. All of these brands interact with our APIs in the same way, so you can rest assured that your application will be compatible across all our appliances.
Our brands are listed below:
How can I find out what specific appliances are supported with the SmartHQ API?
Answer: Learn which appliances support SmartHQ by browsing our selection of smart appliances here.
Will my application be compatible with appliances that will be launched in the future?
Answer: Yes, our appliances produced at a later date will still use our APIs.
Is my application compatible with appliances that are not Wi-Fi enabled?
Answer: Our APIs are only designed for Wi-Fi-enabled appliances. Older appliances that are not able to be connected to Wi-Fi will not be controllable via the SmartHQ API.
What do you mean by "device"?
Answer: In SmartHQ, a device typically refers to a Wi-Fi-enabled appliance—like a dishwasher or air conditioner—connected to the SmartHQ ecosystem. While most devices in SmartHQ are appliances, the term can apply to any internet-connected technology. Through the Device Adapter API, even non-appliance devices (e.g., a Wi-Fi-enabled lawnmower) can be integrated into SmartHQ.
Technical Details¶
What authorization do you use?
Answer: Our developer portal uses the industry-standard OAuth 2.0 security protocol. For more information regarding this standard, please visit the official OAuth 2.0 website here.
When an end-user authorizes an app, can they choose which of their SmartHQ devices the app is allowed to access?
Answer: No. When an end-user authorizes an app, they grant access to their entire SmartHQ account, including all currently commissioned devices. If a device is later decommissioned, that device will no longer be visible or accessible to authorized applications.
Can I let users “Sign in with SmartHQ” to authenticate into my app instead of building my own login system or using another identity provider?
Answer: Not today. SmartHQ’s OAuth 2.0 implementation only allows users to sign in to grant control of their devices to your application—it doesn’t provide ID tokens, a userinfo endpoint, or the discovery documents required by OpenID Connect. You’ll want to continue using your existing authentication system (or another OIDC provider) for user sign-in for your application. However, if your application would benefit from the ability to authenticate with SmartHQ, please contact us.
Do you provide historical API versions? How do you handle API versioning?
Answer: Our APIs are designed to be fully backwards-compatible. Once released, all features remain supported in future updates. Although APIs have version numbers, we only publish the current, latest version and do not maintain historical versions to access directly. There is no way to access the version of an API from a year ago. Accessing an older version is not necessary because we currently support everything from that version and more with recent updates. We continuously evolve the SmartHQ Data Model by adding new properties or endpoints directly to the current version. We do not currently support a change log of new features, as the demand to see changes is not present. If you are interested in receiving updates about new features as they become available, please contact us.
Where do I send my API requests to?
Each API call is an HTTP request asking a server to perform some action and return data. In the API specifications, you’ll find one or more server entries. Each server has a base URL, which is the root address your request will hit. Using the Identity and Access Management API as an example, the requests are made to a server located at:
This specific server URL can be found at the top of the Identity and Access Management specification under the 'servers' section. Each API specification will have a different server.
Each endpoint listed in the API specification such as GET /oauth2/auth is a specific request to make to the server. That request is sent as part of the URL itself by appending it:
Oftentimes, there is more information that needs to be sent to the server, which can be appended as query parameters. These query parameters can be found in the API specifications, such as these query parameters:
https://accounts.brillion.geappliances.com/oauth2/auth?response_type=code&client_id=<Your-ClientId>&redirect_uri=<Your-RedirectUri>&access_type=offline&state=<someValue>
Typically, the response from an API is JSON. This authorization endpoint however is an exception that returns HTML for a web page for a user to sign into (Learn more).
How do I send API requests?
For a practical guide, see Getting Started.
Ultimately, your HTTP client (a web browser, curl, Postman, or a library in your code) opens a connection to the SmartHQ server hosting the API and sends your request.
Browser vs. programmatic requests
-
GET endpoints: You can often paste the full URL into a browser to see the JSON response (or other response types, such as HTML) from the server.
-
POST/PUT/DELETE, etc.: These require a request body and headers (for example,
Content-Type: application/json), so you’ll want to use curl, Postman, or your HTTP client library. Some endpoints expect form-encoded bodies (application/x-www-form-urlencoded) (often to protect secrets); the endpoint docs will call this out—e.g.POST /oauth2/token.