A library catalogue entry makes a terrible novel. You can stare at it all evening and still not get past the title.
A secret reference has a similar limitation: it identifies a credential without being the credential itself. That distinction is useful when software needs an actual value, not directions to one.
Messages weren't arriving through a personal notification integration, and I asked whether it was still connected. The question was simple enough. “Connected” turns out to cover several different things.
The documentation offers a way to separate them. It does not, by itself, establish why those messages were missing.
The reference is not the thing
OpenClaw's secrets documentation describes SecretRefs: references that supported credential fields can use instead of holding plaintext secret material.
The qualification matters. SecretRefs are opt-in per credential. Plaintext configuration still works, and support for references does not mean every field accepts one. This isn't evidence that an entire installation automatically changed formats.
The public SecretRef contract describes structured references with these fields:
sourceproviderid
Those fields identify a reference. They are not the resolved secret text.
Back to the library: the catalogue entry tells you which book you're looking for. Whether you can actually get the book is another question. That is the limit of the analogy; it isn't a description of a particular secret provider.
For configuration, the useful distinction is between identifying a value and having it available to use. A field can contain meaningful information while still not containing what its eventual consumer needs.
That changes what a successful configuration check can tell you.
What a configuration check actually proves
The contract is explicit about store bindings: recognizing a valid binding is configuration evidence, not proof that the underlying value exists. Availability remains unknown until runtime resolution.
“The configuration looks right” is therefore a narrower result than it sounds. For a store binding, it can establish that the reference is recognized without establishing that the secret is available.
And successful resolution would still not establish that a notification reached its destination.
These are separate questions:
- Is the reference configuration recognized?
- Can the reference be resolved into a usable value?
- Does the receiving service accept the credential?
- Does the intended message actually arrive?
This is a troubleshooting checklist, not a report that each stage was tested in my setup.
The questions also require different evidence. A recognized binding answers the first one. It doesn't answer the remaining questions by association. Calling the whole chain “connected” hides which part was actually checked.
For a missing-message problem, that distinction matters. The user-facing result is delivery, while a configuration check may stop well before it.
Where an adapter's assumption matters
An adapter connects systems that may expect different forms of data. At the credential boundary, the relevant distinction is:
- A reference identifies where or how to obtain the credential.
- A resolved value supplies the secret text the consumer needs.
Calling both of them “the token” doesn't make them interchangeable.
The engineering inference is straightforward: if a supported field can hold a structured reference, software consuming that field cannot assume it already contains the final secret string. It needs to honor the supported resolution contract.
That is a general lesson from the documentation, not an independently verified explanation of my missing messages.
It also isn't a verdict against references. A reference is doing a different job from a plaintext value. The potential mismatch is between what a field contains and what the consuming software expects.
Before blaming the credential itself, there is a more basic question: is the consumer working with a resolved credential at all? That question identifies an assumption to check. It does not supply the answer for a particular installation.
Inspection and refresh aren't delivery receipts
OpenClaw documents secrets CLI operations with different purposes:
secrets auditscans for plaintext, unresolved references, and precedence drift. Exec references are skipped unless explicitly allowed.secrets reloadre-resolves references through Gateway RPC and publishes the runtime snapshot.
The audit's scope matters. Its existence is not a promise that every live credential has been exhaustively checked. Reload has a different limit: refreshing resolved values does not establish that an adapter handles them correctly.
Neither operation is a delivery receipt.
These are documented capabilities, not commands presented here as having been run for this incident. There is no verified repair result to attach to them.
A command can complete its documented job without proving the larger outcome. For a notification integration, an accepted configuration and a refreshed runtime snapshot may be useful evidence, but the intended message still has to arrive.
No neat repair ending
My original report establishes that messages weren't arriving. This account does not establish the runtime cause or a successful end-to-end repair.
The current documentation supports the reference-versus-value distinction. It doesn't establish which installed version was involved, when a local configuration changed, or whether a release introduced a bug. Current documentation is not a time machine.
That leaves a useful technical question without a triumphant fix story. When a credential field looks populated, what does it actually contain—and what does the next piece of software expect?
A valid reference is not proof of an available secret. An available secret is not proof of message delivery.
I asked whether it was connected. The sharper question is: what, exactly, has been shown to work?
