Experiment record

Rinnai API 401 ERR_0010: recovering a Kantakun Apps Script collector

A Kantakun collector running in Google Apps Script failed with Rinnai HTTP 401 / ERR_0010 ('invalid token'). The retained code showed a bearer token stored in Script Properties and a 401 path that stopped immediately instead of renewing credentials. The operator later resolved authentication in Work mode; the exact recovery step is not present in the evidence available to this publication step, so it is deliberately not reconstructed.

Conclusion

The observed failure was an authentication failure in the Rinnai API path, not a general Google Apps Script outage and not a failure of the Kantakun operating-state logic.

The Apps Script execution log recorded HTTP 401 together with Rinnai ERR_0010 and the message that the token was invalid. The failing call originated in rinnaiGet_(), which was reached through pollKantakun_() and pollKantakunHourly().

The retained implementation read a bearer token from Apps Script Script Properties and sent it in the Authorization header. Critically, the retained rinnaiGet_() code stopped on HTTP 401. It did not contain a verified token-renewal flow followed by a bounded retry.

The operator subsequently reports that the authentication problem was resolved in Work mode. The exact corrective action from that separate session is not present in the evidence available to this publication step. Therefore this record does not claim that a particular refresh endpoint, refresh token, login flow, header change, or token lifetime was confirmed.

System context

The integration work used Google Apps Script as an unattended collector for household energy and equipment data. Rinnai/Kantakun data was being added alongside other scheduled collection jobs.

During protocol investigation, the mobile application traffic had been observed through a local HTTPS inspection setup. That work established enough request structure to test selected Kantakun endpoints from Apps Script. Authentication secrets and installation-specific identifiers are not reproduced here.

The relevant data path was conceptually:

Google Apps Script
  -> Rinnai API request
  -> bearer credential from Script Properties
  -> Kantakun state / utility-cost response
  -> collection logic

Symptom

A scheduled execution failed with a response equivalent to:

HTTP 401
errorCode: ERR_0010
message: token is invalid

The stack trace identified this path:

rinnaiGet_()
  -> pollKantakun_()
  -> pollKantakunHourly()

At the same time, other collection executions visible in the Apps Script history completed normally. That was useful negative evidence: Apps Script itself was still running scheduled work, while the Rinnai request alone failed authentication.

Retained authentication design

The implementation retained in the troubleshooting record used Script Properties rather than embedding the bearer token directly in ordinary runtime code:

const token = PropertiesService
  .getScriptProperties()
  .getProperty('RINNAI_TOKEN');

The request then used the stored value as a bearer credential.

The important failure-handling behaviour was this: when the API returned HTTP 401, the retained implementation raised an error and stopped. In other words, the code expected the stored credential to remain usable and had no verified renewal sequence in that path.

That distinction mattered because earlier design discussions had assumed that unattended operation should eventually include automatic credential renewal. The code actually running at the time of the incident did not demonstrate that behaviour.

What the 401 established

The combination of HTTP 401 and Rinnai ERR_0010 established a narrow diagnostic boundary:

• the request reached the Rinnai service;
• the service rejected the credential presented with the request;
• the failure occurred before useful Kantakun payload processing;
• spreadsheet aggregation and Kantakun state-transition logic were downstream of the failure.

It did not establish why the credential became invalid. Possible mechanisms such as expiry, revocation, application re-login, refresh-token rotation, or malformed authorization formatting require direct evidence before being stated as fact.

Recovery

The operator reports that the authentication error was resolved in Work mode after this diagnosis.

The separate Work-session change record is not available to this publication step. In accordance with this project’s evidence rules, the missing detail is left as an unknown rather than reconstructed from memory. Specifically, this public note does not assert whether the successful recovery used:

• replacement of the captured bearer token;
• a refresh-token exchange;
• a fresh login/authentication exchange;
• corrected headers;
• or another implementation change.

The verified outcome is limited to the operator’s report that authentication was restored.

Long-running collector design

The incident exposed a general design requirement for unattended API collection: credentials have a lifecycle.

A robust implementation should distinguish ordinary API failure from an authentication event. The target control flow is conceptually:

API request
  -> 2xx: process normally
  -> 401 / verified invalid-token response:
       execute the verified renewal mechanism
       update secret storage
       retry once
       if still unauthorized, fail closed and log a non-secret diagnostic

The renewal mechanism itself must not be invented. It should only be implemented after observing or documenting the actual service flow.

A one-retry limit is important. An invalid credential should not create an uncontrolled re-login or retry loop inside a time-driven Apps Script trigger.

Secret handling

For this type of integration, the public repository should contain only placeholders and control logic. Runtime credentials belong in a secret store such as Apps Script Script Properties or an equivalent managed secret facility.

Logs should record values such as HTTP status, provider error code, execution path, and whether a renewal attempt occurred. They should not print bearer tokens, refresh tokens, full authorization headers, account identifiers, or private controller identifiers.

The same rule applies to captured mobile traffic: request traces used for reverse engineering may contain credentials even when the API payload itself looks harmless.

Relationship to Kantakun energy collection

The authentication incident occurred during work to collect Kantakun operating state and utility-cost information. Earlier observation had shown that the state endpoint could reflect operating state such as WORKING, while the utility-cost endpoint returned a gas-cost value displayed by the application in yen.

Those observations are separate from the authentication conclusion. A 401 must be resolved before any downstream logic for delayed cost settlement, gas-cost conversion, polling cadence, or spreadsheet aggregation can operate reliably.

AI-readable summary

Verified: Rinnai returned HTTP 401 / ERR_0010 indicating an invalid token. The failing function was rinnaiGet_(). The token was read from Script Properties. The retained 401 handler stopped instead of performing a verified automatic renewal. Other Apps Script collection executions were still completing. The operator later reported that Work mode restored authentication.

Inferred: unattended operation requires explicit credential-lifecycle handling rather than indefinite reuse of one bearer token.

Unknown: the exact token lifetime and the exact successful Work-session recovery operation are not present in the evidence available here.

Do not publish: bearer tokens, refresh tokens, controller IDs, account identifiers, private-network details, or intercepted authorization headers.