Architecture·May 2024·9 min read

Smart Home Devices and Web Integration: Opportunities for Developers

Matter standardized the device layer in 2022, not the app layer. There is still no browser API for talking to a Thread mesh or a Matter device directly. What a web or backend developer actually integrates against is a cloud account-linked API — Alexa's Smart Home Skill, a vendor's REST API, or eventually Google's Home APIs — and the "smart home as a checkout button" idea already had its run and ended.

What Matter actually standardized

Before Matter, buying a smart bulb meant picking an ecosystem — Alexa, Google Home, Apple Home, or a vendor's own app — and hoping it didn't change. Matter, developed by the Connectivity Standards Alliance with Amazon, Apple, Google, and others as founding members, gives a single certified device a shared language those ecosystems can all speak (GitHub — project-chip/connectedhomeip).

It runs over Wi-Fi, Ethernet, or Thread's low-power mesh network, with Bluetooth Low Energy used only for the initial commissioning handshake. Google's own developer documentation frames it plainly: Matter is a device compatibility layer, and Google Home APIs sit on top of it as the actual thing a developer builds against (Google Home Developers — What is Matter?).

That distinction is the one teams get wrong first. Matter is not an API you call. It's the reason a device your customer already owns is reachable by the cloud APIs described below, regardless of which brand made it.

The mesh underneath: Thread

Thread is the low-power, IPv6-based mesh networking protocol Matter runs on for battery-powered devices like locks and sensors, as an alternative to Wi-Fi (Thread Group). Devices relay through each other rather than each needing a direct Wi-Fi connection, which is why a Thread border router (often built into a smart speaker or hub) shows up as a required piece of hardware in most Matter setups.

None of that mesh is reachable from a browser, or from a typical cloud backend, without going through a border router and the ecosystem controller sitting behind it. That's a second reason "the web talks to the device" is the wrong mental model — there's a physical hub in between even when the marketing calls it a "smart home API."

Where a web developer's integration point actually is

None of this is reachable from a browser directly. Web Bluetooth exposes low-energy GATT operations to a page, but it has no concept of a Thread mesh or a Matter fabric, and no mainstream smart home flow relies on it for device control (MDN — Web Bluetooth API). Integration happens one layer up, against whichever ecosystem's cloud API a customer's devices are already linked to.

Ecosystem	What a developer actually builds	Reachable from a plain web backend?
Matter (device layer)	Nothing directly — commissioning happens through a companion mobile app, not your code	No
Amazon Alexa Smart Home Skill	A Lambda function or HTTPS endpoint that receives JSON directives and returns JSON events, plus OAuth2 account linking	Yes — this is a normal backend service in any language
Google Home APIs	Native Kotlin (Android) or Swift (iOS) SDK integration	No general web/REST surface as of 2026; mobile-only
Apple HomeKit	Native Swift framework integration	No — mobile/native only
Vendor cloud REST API (e.g. Philips Hue)	Plain OAuth2-authenticated REST calls against the vendor's own cloud	Yes, and often the most practical path for a specific device brand

Google's own Home APIs documentation is explicit about the target audience: "Develop for Android with our streamlined APIs that make it easy to build using Kotlin on Android and Swift on iOS" (Google Home Developers — Home APIs). If your team is a web shop without a mobile app, that path isn't available to you today, regardless of how much Matter marketing implies universal device access.

The practical path: building a Smart Home Skill backend

Of the ecosystems above, Alexa's Smart Home Skill API is the one that looks like ordinary backend work. A developer builds a Lambda function (or any HTTPS endpoint Alexa can reach) that responds to discovery requests, receives directives, and returns events (Amazon Developer — Understand the Smart Home Skill API). The broader Alexa Skills Kit that this sits inside of is documented the same way: APIs, tools, and an account-linking flow, not a proprietary hardware SDK (Amazon Developer — What is the Alexa Skills Kit?).

{
  "event": {
    "header": {
      "namespace": "Alexa",
      "name": "Response",
      "messageId": "abc-123"
    },
    "payload": {}
  },
  "context": {
    "properties": [{
      "namespace": "Alexa.PowerController",
      "name": "powerState",
      "value": "ON"
    }]
  }
}

That's a JSON directive-response contract any backend team already knows how to build and test. The unfamiliar part is the account-linking UX: a customer authorizes your service inside the Alexa app via OAuth2, and your skill has to handle token refresh and re-linking the same way any third-party integration does.

Alexa organizes device functionality into capability interfaces — PowerController for on/off, BrightnessController for dimming, and dozens more — each with its own defined set of directives and properties. A skill declares which interfaces its devices support, and Alexa handles matching voice commands to the right directive, so the integration work is mapping your device's actual capabilities to the closest existing interface, not designing a voice command grammar from scratch.

The reorder-button experiment, and why it ended

The Amazon Dash Button, launched in 2015, let a customer press a physical button to reorder a specific product with no app or web page involved. Amazon's own developer team later described its limitation plainly: "Dash Buttons were convenient; however, the customer still had to have an awareness of their inventory, and they had to remember to push the button" (Amazon Developer — Dash Button evolution to Alexa Smart Reorders).

Amazon "sunset the concept of a physical button" and replaced it with Alexa Smart Reorders, which launched in 2019 and predicts and places reorders automatically based on usage, without requiring the customer to do anything. By Amazon's account, the program has grown at a 100% year-over-year rate since launch, alongside more than 300 million smart home devices connected to Alexa overall.

The commerce lesson from Dash isn't "hardware reorder buttons don't work." It's that a UI requiring a customer to remember and act loses to one that predicts and acts for them. That principle outlived the specific device.

For a web team today, the practical version of "smart home commerce" isn't a physical button or a smart-fridge checkout flow. It's predictive reordering logic that runs against a customer's existing purchase history — the same pattern Alexa Smart Reorders proved out, implementable without any smart home hardware dependency at all.

For a D2C brand specifically, that's the actual takeaway from the Dash Button's retirement: the reorder logic (consumption modeling, a low-stock trigger, one-tap confirmation) is the reusable part. The hardware button was one delivery mechanism among several — email, app notification, SMS work the same underlying model without a device dependency at all.

Failure modes teams hit on the first attempt

Assuming Matter is an API. It's a device compatibility spec. The API you actually call still belongs to whichever ecosystem the customer's device is linked to.
Assuming a browser can commission a device. Commissioning is a mobile-app job today, using BLE and a QR code — there's no equivalent web flow.
Underestimating the OAuth2 account-linking UX. A customer has to explicitly authorize your service inside another company's app; a broken or confusing linking flow kills adoption before your integration code ever runs.
Building for one ecosystem and assuming portability. An Alexa Smart Home Skill and a Google Home integration are separate builds with separate account-linking flows and separate certification processes — there's no single Matter-flavored integration that reaches all three assistants at once.
Treating "smart home" as a single market. A voice-control integration (Alexa, Google Assistant) and a local-control integration (a companion mobile app talking Matter over Thread) solve different problems and have almost no code in common.
Skipping certification timelines in the project plan. An Alexa Smart Home Skill goes through a certification review before it's publicly available, and a Matter-certified hardware device goes through the Alliance's own compliance process — both add real weeks to a launch date that a software-only estimate will miss.

A scoping checklist before committing engineering time

Identify which specific customer action you're trying to enable: voice control, automated reordering, or in-home device status.
Confirm whether that action requires a mobile app (Matter commissioning, Google Home APIs, HomeKit) or can be built as a pure backend service (Alexa Smart Home Skill, a vendor REST API).
If voice control is the goal, scope one assistant's skill/action framework at a time — there's no shared integration layer across Alexa, Google Assistant, and Siri.
If the goal is commerce-adjacent (reordering, replenishment), evaluate whether the smart home hardware is even necessary, or whether predictive logic against existing purchase data solves the same problem without it.
Plan for OAuth2 account linking and token refresh as a first-class part of the build, not an afterthought.

FAQ

Does Matter mean I can build one integration that works everywhere?

No. Matter unifies the device, not the app layer. You still build a separate integration per ecosystem — Alexa, Google, Apple — each with its own API and account-linking flow.

Can a website talk directly to a Matter device?

Not today. There's no browser API for Thread, and Web Bluetooth's scope stops at BLE GATT operations, which isn't how Matter devices are commissioned or controlled in practice.

Is the Amazon Dash Button coming back in another form?

The physical button is retired. Its successor, Alexa Smart Reorders, replaced the "remember to press a button" model with automatic, usage-based reordering — the pattern worth building toward, not the hardware.

Is Google Home API integration realistic for a web-only team?

Not as of 2026. Google's own documentation scopes the Home APIs to native Android (Kotlin) and iOS (Swift) development, with no general REST surface for a plain web backend.

What's the fastest smart-home-adjacent integration a web team can actually ship?

An Alexa Smart Home Skill backend, because it's a standard HTTPS/JSON service any backend team can build without a mobile app or new language.

Do we need our own hardware to build any of this?

No, if the integration target is an existing device category customers already own — a smart plug, a thermostat, a lock. You need hardware only if the product itself is the device, in which case Matter certification becomes a real line item in the project timeline.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.