When a connection stops working, Steuard says so in four places: a red notice at the top of every admin screen, the connection card's status, the Data Freshness row on the Dashboard, and the front-end cache bar if it is on. All four carry the same message, with the date and the reason, and link to the fix.
Open the connection card and start with its status:
- Connected — the saved credentials passed the latest live check, and menus or reviews have been fetching normally.
- Needs attention — one of three things, and the card says which:
- Toast rejected the saved credentials on [date] (HTTP 401) — the Client Secret on file with Toast no longer matches the one saved here. Get the current credential from Toast and re-enter it. Nothing in Steuard can repair this; the menu keeps showing the last good copy until you do.
- The saved Client Secret can't be read — the site's security keys or salts have changed — usually a database copied to another site, or rotated keys. Re-enter the secret; see What should I do after WordPress salts are rotated?.
- Toast hasn't answered since [date] — the provider has been unreachable for longer than a refresh cycle. Check Toast's status and your host's outbound connectivity; a short outage clears itself on the next successful refresh.
- Not tested — the saved values have not completed a live check yet. Click Save Changes; Toast connections can also use Test Connection.
- Incomplete — a required credential, restaurant location, or business selection is missing.
A status can only return to Connected by a live check passing (Test Connection or Save Changes) or by the next fetch succeeding. The admin notice can be dismissed for the current incident; it comes back if the connection fails again later.
The Credentials, Locations or Business, and Site-wide refresh rows report different parts of setup. A connection can have valid credentials while no location is selected, or be connected while the latest site-wide data refresh is old.
Toast POS failures #
Confirm that Provider Type is Toast POS, then re-copy the API hostname, Client ID, and Client Secret with no leading or trailing spaces. In Toast Web, confirm that the credential still includes the location and at least the menus:read scope. See Where do I find my Toast credentials?.
If authentication succeeds but Fetch Locations from API fails, your credential may not have access to Toast's restaurant-list endpoint. Enter each location's GUID with + Add Location, click Save Changes, and check the Toast menu dropdown on a Toast Menu post. See Why are locations or menus missing?.
Google Places key, billing, or quota errors #
On the Review post's Connection tab, open Fix common Places errors in the Before you begin panel:
- HTTP 400 — re-copy the API key, search for the business again, choose the correct result, and save.
- HTTP 403 — turn on billing and Places API (New), then allow the server's public outbound IP in the key restrictions.
- HTTP 429 — check the Places API quota in Google Cloud and try again after the rate limit resets.
- No search results — search with the exact business name plus its city or street address.
For initial setup, set Application restrictions to IP addresses and add the public outbound IP address your web server uses for Google requests. Set API restrictions to Restrict key → Places API (New). Do not use Websites (HTTP referrers) because Steuard sends the request from the server. See Displaying Google Reviews for the complete setup.
Every connection failed after a site change #
Your WordPress security keys and salts in wp-config.php may have been rotated. Steuard encrypts saved credentials with those values, so rotation makes the old encrypted secrets unreadable. Follow What should I do after WordPress salts are rotated?.
If the connection still fails, send support the safe diagnostic details in What should I send Steuard support?. Never send a Client Secret, API key, refresh token, or license key.
