Skip to main content

​
Resolving actions

Collecting a pending action tells you what needs to happen. This page covers the other half — actually resolving it: starting the action, redirecting the end-user, and reporting the outcome so the item clears.
Discover pending actions first with Fetch the notification content (webhook-driven) or List what needs attention (polling). Both hand you an action carrying the resolution_link this page acts on.
Every action is self-describing — you act on it without knowing the device type. You start from its resolution_link:
The url is relative (prefix https://app.podero.com) and already embeds the action’s cue_id and a signed secret — send it verbatim, never construct it yourself. Branch on the action’s code; each code names its own required_parameters.
The secret is bound to the notified user and expires one hour after it is issued. If it expires before the user acts, re-collect the action to obtain a fresh link.

​
Resolve a reauthenticate action

A reauthenticate action means a device’s manufacturer connection has lapsed and optimization is paused for it. Resolving it is a three-call flow.
1

Start the action

POST the resolution_link.url, supplying the fields named in required_parameters. This call needs both your bearer token and the signed secret.
The response carries the manufacturer flow to send the user into:
2

Redirect the end-user

Send the user to redirect_url. They re-authenticate with the manufacturer in Podero’s hosted flow, then land back on the success_url (or cancel_url) you supplied. The redirect_url is single-use and tied to this action — start a fresh action per user, don’t cache it.
3

Report the outcome

From your success_url / cancel_url handler, report the result. This call is authenticated by the secret alone — no bearer token.

​
Resolve an information action

An information action is a notice to show the user (metadata.message), not a flow to walk. It has no required_parameters and is resolved — dismissed — by a single call to its resolution_link, with no body:
The notice is marked read: it leaves the pending list and the information_available count, but stays retrievable in history via GET /notifications/information with dismissed: true.

​
Lifecycle & semantics

Understanding the state machine behind an action keeps your integration correct under retries and expiry.
The secret inside every resolution_link.url is bound to the notified user and expires one hour after it was issued. Resolve promptly. If a call returns 404, the secret has expired or the action is already resolved — re-collect the action to obtain a fresh resolution_link, then retry.
Submitting success twice for the same action returns the same action_id and does not double-resolve. Safe to retry the report call after a network error.
Reporting fail records the attempt but leaves the action pending, so the user can try again. Only success clears it.
Start (/resolve) needs your bearer token and the secret. Report (/state) and the information dismiss need the secret only — the signed token is the authorization, so these can be called from a lightweight redirect handler without your API credentials.

​
Forward compatibility

Every action is fully described by its own code, resolution_link, and required_parameters. Your resolver branches on code, calls the url with the parameters it names, and reports the outcome — no device-type-specific logic, no hand-built URLs. When Podero introduces a new action code, it flows through the resolver you already wrote; you only add rendering for the new code.

​
Next steps

Notifications journey

The end-user-facing walkthrough: badges, lists, and resolution in your app.

Reference

The message envelope, topics, and the Notification Content API.