API_ONLY app: OAuth authorize fails with "An unexpected error occurred" (4 reference IDs)

Developer Programs Support
1

I am setting up a personal, non-commercial integration that reads the status
and power consumption of my own Samsung washing machine, to calculate monthly
running costs against a dynamic electricity tariff.

Since newly created Personal Access Tokens expire after 24 hours, I followed
the recommendation to use the authorization_code OAuth flow. The flow fails
reproducibly at the authorization step with “An unexpected error occurred”.

All attempts on 4 September 2026, apps created with SmartThings CLI 2.1.2 via
“apps:create”, which completed successfully and returned client credentials.

  1. App ff73da92-f9b5-417d-8963-3538ac0d7b7d
    API_ONLY, principalType LOCATION
    redirect http://localhost:8973/callback
    scopes r:locations:* r:devices:* x:devices:*
    Reference ID 768a8f99-97d0-75d7-7007-bb2d56cd2d58, 15:26:22

  2. App 38355e29-00d1-43cd-a1b0-60fc95f09a72
    API_ONLY, principalType USER_LEVEL, same redirect and scopes
    Reference ID b3a4816c-4efe-b346-e331-d7f019d1de6a, 15:28:42

  3. Same app, redirect changed to https://localhost:8973/callback
    Reference ID 6fc45050-25a1-d479-4566-579386886b9f, 15:31:10

  4. Same app, https redirect, scope reduced to r:devices:* only
    Reference ID 9ac956b2-a88d-a2b5-3671-471fd89721cf, 15:33:26

Observations:

  • SmartThings. Add a little smartness to your things. returns a bare HTTP 403 from the
    load balancer, with no SmartThings error page.
  • SmartThings. Add a little smartness to your things. works up to the Samsung
    login. The error appears only after signing in, when the authorization is
    processed. That looks like a backend failure rather than a malformed request.
  • Each attempt used a fresh browser tab, so stale session data is ruled out.
  • A Personal Access Token with the same scopes works fine against the same
    device, so account and device are not the problem.
  • I switched from http to https for the redirect URI after reading that
    localhost over http is known to cause problems. It made no difference.

Questions:

  1. Is this a known defect, and is there a configuration for an API_ONLY /
    OAuth-In app that currently works?

  2. The Developer Workspace is no longer available for new integrations after
    31 August 2026, and the release notes of 30 June 2026 mention a transition
    to paid API access. Are personal, non-commercial integrations still
    supported? If so, which path should be used going forward?

  3. If personal OAuth integrations are no longer possible, is there a supported
    way to obtain a long-lived token, or is creating a new Personal Access
    Token every 24 hours the intended behaviour?

Thanks for any pointers.

2

It has been a while since I played around with these apps and encountered the various errors.

The demise of the Developer Workspace means, or will mean, there is no longer a place to usefully create Webhook/Lambda SmartApps unless you use the API directly and know the undocumented ways of installing them without publishing them to the mobile app. They have now completely vanished from the documentation so I assume they no longer want us to use them. It’s not like we ever had full access to what they could do. I haven’t yet read the API Access documentation that replaced Webhooks as I’d figured things out long before it appeared, but I probably should.

The use of API Access is now encouraged, and was specifically suggested instead of using PATs (which are realiy meant as part of the development/test process and are tedious to create and can’t be renewed).

Having got us using API Access apps, it turns out having one makes us non-commercial developers, which will mean a monthly subscription unless there are free levels of access we haven’t yet been told about.

Although User Level access is needed to directly replace PATs I never got it to work and was told that it actually required bespoke handling on the ST end. So unless things have changed you are limited to the Location Level.

Do you actually have something listening on the localhost? I got the impression that the OAuth server checked for the existence of the redirect URL, which makes little sense with localhost even if there is something listening so it may be wrong. When giving an examples of creating an API Access app just to get tokens I used https://httpbin.org/get as the redirect.