Skip to main content
When something goes wrong with an inventory source, your setup surfaces show a diagnosis: what is wrong, whether it needs you, and the one action that fixes it. This page is the reference behind those diagnoses. Every problem listed here is one you can fix — problems on our side never appear as your tasks; they show as a passive status line while we work on them. Each diagnosis in the product links to its section below.

​
Ad server credentials invalid

What it means. Your ad server (Google Ad Manager, FreeWheel, SpringServe, or AdsWizz) rejected the credentials on file, so inventory, pricing, and orders stop syncing. This usually happens after a password rotation, a revoked API token, or a removed service-account user. Who fixes it. You. The credentials belong to your ad-server account, so only you can issue or restore them. How to fix it.
  1. Open the ad-server setup surface (the diagnosis carries a Reconnect ad server button that takes you there).
  2. Re-enter the credentials for your ad server. Saving tests the connection before it commits, so a typo cannot make things worse.
  3. For Google Ad Manager, the connection uses a service account instead of a password — confirm the service-account email is still an active user in your GAM network with inventory and trafficking access. See Grant ad-server access.
Why this step exists. We never store or guess a working credential on your behalf; syncing resumes only when your ad server accepts the connection again.

​
Agent credentials missing

What it means. You connected a third-party sales agent that requires authentication, but no credentials have been added yet. The agent cannot sell until it can be called. Who fixes it. You. The credentials come from whoever runs the agent. How to fix it.
  1. Get the API key or basic-auth credentials from your sales-agent provider.
  2. Open the diagnosis’s Add agent credentials action — it opens a secure in-chat form that stores the credentials encrypted.
  3. The connection is verified automatically; the task clears once the agent responds.
Why this step exists. The agent is yours (or your vendor’s), so its credentials have to come from you — we cannot mint them.

​
Source unreachable

What it means. A sales agent you run stopped responding, so its inventory cannot sell until it is reachable again. Who fixes it. You, when the source is an agent you (or your vendor) operate. If the unreachable source is one we host for you, it never appears as your task — we are alerted internally and fix it ourselves. How to fix it.
  1. Check that the agent is running and reachable at its registered endpoint URL.
  2. If the endpoint moved, update the source’s endpoint in the source setup surface.
  3. Use the diagnosis’s Run discovery test action. It makes a read-only get_products call and clears the task only when that inventory operation completes successfully.
Why this step exists. Buyer requests are answered live by your agent; an unreachable agent means missed sales, not just a warning.

​
Source responding with errors

What it means. A sales agent you run is reachable but returning errors on some requests. It can still sell, but it is degraded and worth a look. Who fixes it. You, for agents you operate — usually by checking the agent’s own logs. How to fix it.
  1. Check your agent’s logs for the failing requests (the diagnosis shows the most recent error code we saw).
  2. Fix the failing behavior on the agent side.
  3. Use the diagnosis’s Re-check connection button to re-run the health check without leaving the surface.
Why this step exists. Intermittent errors reduce the share of buyer briefs your storefront answers; catching them early protects your win rate.

​
Trafficking errors

What it means. One or more buys could not be created in your ad server. The buy is sold but not yet delivering, so it needs attention promptly. Who fixes it. You. Trafficking errors are almost always an ad-server-side condition — a missing permission, a missing default advertiser, or a value your ad server rejected. How to fix it.
  1. Open the diagnosis’s Resolve trafficking error action — it shows each failed buy with the ad server’s own error message.
  2. Fix the condition in your ad server (or in the source configuration) and retry the buy from the same surface.
Why this step exists. A buy that never reaches the ad server never delivers and never bills; this is the shortest path from “sold” to “live”.

​
Wholesale pricing out of date

What it means. A source that supplies its own wholesale pricing has a feed older than the freshness window (or no feed at all). Its products come off the market until a current feed is uploaded, so buyers are never quoted stale prices. Who fixes it. You. The pricing feed is produced by your side. How to fix it.
  1. Export a current wholesale pricing file in the same format as your last upload.
  2. Open the diagnosis’s Upload wholesale pricing action and upload the file. Products return to the market as soon as the feed is current.
See Wholesale avails and pricing for the file format and freshness window. Why this step exists. Selling on stale prices risks quoting buyers a price you no longer honor; pulling the products is safer than guessing.

​
Some wholesale products have no eligible ad-server pricing

What it means. Interchange found no current non-guaranteed commercial pricing for those products. We use Price Priority, Network, and Bulk demand for this pricing. House demand has no commercial buyer price; Sponsorship and Standard demand are guaranteed and are not converted into non-guaranteed CPM guidance. How to fix it. Upload pricing rows for the unresolved products. Products that already have eligible ad-server pricing keep it, so the upload does not replace the entire source’s pricing.

​
Catalog can’t be read

What it means. We tried to refresh your product or signal catalog from your ad server and the request was refused for authorization reasons — the connection can no longer sign in with enough access to read the catalog. Who fixes it. You, when the error is an authorization error (the diagnosis says so and carries a Reconnect ad server action). Any other catalog read failure is ours to fix and shows only as a passive status line. How to fix it.
  1. Reconnect the ad server with working credentials (see Ad server credentials invalid).
  2. For Google Ad Manager, confirm the service account still has inventory read access in your network.
  3. The catalog refreshes automatically after the connection is restored.
Why this step exists. Buyers discover your products from this catalog; if we cannot read it, buyers gradually see an out-of-date storefront.

​
Reporting access missing

What it means. Your ad server accepted the connection and inventory keeps syncing, but it denied the specific permission scope we need to pull delivery reporting (for example, FreeWheel’s reporting scope, or a Google Ad Manager service account without reporting access). This is narrower than Ad server credentials invalid: inventory, pricing, and orders are unaffected — only reporting is blocked, so this never stops you from selling. Who fixes it. You. The reporting scope is a permission your ad-server account grants; we cannot request it on your behalf. How to fix it.
  1. Open your ad server’s account/permissions settings and grant the reporting scope to the service account or API user Scope3 connects with.
  2. For Google Ad Manager, confirm the service-account email has reporting access (not just inventory/trafficking) in your network. See Grant ad-server access.
  3. For FreeWheel, confirm the API user has the reporting API scope enabled in the FreeWheel account.
  4. After FreeWheel confirms the permission is live, select Access confirmed - re-check reporting on the diagnosis. Interchange does not keep polling a capability that FreeWheel has reported as unprovisioned; a successful re-check resumes the paused reporting sync.
Why this step exists. Delivery reporting is a separate permission from inventory and trafficking on most ad servers, so it can be missing even when everything else works — we surface it on its own so you know exactly what to grant, instead of a generic “reconnect” that overstates the problem.

​
Forecasting access missing

What it means. FreeWheel accepted the base connection but has not enabled forecasting for the API user. Inventory, orders, and selling are unaffected; forecast estimates are unavailable until FreeWheel provisions this separate capability. Who fixes it. FreeWheel provisions this permission. Ask your FreeWheel representative to enable forecasting for the API user Scope3 connects with. How to fix it.
  1. Ask FreeWheel to enable the forecasting API capability for the API user.
  2. Wait for FreeWheel to confirm the grant is live.
  3. Select Access confirmed - re-check forecasting on the diagnosis. A successful check resumes forecasting; Interchange does not poll the denied capability while it is awaiting vendor permission.
Why this step exists. Forecasting can be provisioned separately from the base FreeWheel connection. Keeping it as a focused, non-blocking task avoids reconnecting valid credentials or blocking inventory and order workflows.

​
No products published yet

What it means. Your ad server is connected and syncing correctly, but no sellable Interchange products are currently mapped to that source. This does not mean the inventory sync is empty: ad units, placements, and other synced inventory can be available before you package it into products. Buyers have nothing to transact on until at least one product is available. Who fixes it. You. Build products in Interchange from the synced inventory, or import them through a supported product feed. Only you can decide how that inventory should be packaged and sold. How to fix it.
  1. Open the diagnosis’s Build products action — it takes you to the product-building surface where you package inventory into sellable products.
  2. Select the synced inventory that the product should package. For Google Ad Manager, you can browse placements and ad units, including their hierarchy.
  3. If you use a supported product feed, confirm the products are mapped to the inventory this storefront sells.
  4. The task clears once at least one sellable product is available.
Why this step exists. We never invent products on your behalf — what buyers can purchase is your commercial decision, so the catalog stays empty until you publish it.

​
Products hidden from buyers

What it means. Your storefront is live and transacting, but every product buyers could see has been hidden by our buyer-visibility check — most often because manual pricing expired, an operator fixed price is set in a different currency than your storefront’s settlement currency, or ad-server-derived pricing went stale. The products still exist and are still syncing; buyers simply can’t purchase any of them right now. Who fixes it. You. Upload current wholesale pricing and availability (or connect ad-server pricing history), or correct the mismatched currency on the affected fixed prices. If the cause is stale ad-server pricing, check the ad-server connection instead — no upload is needed. Ad-server pricing staleness. Pricing derived from ad-server reporting history has a 60-day freshness ceiling: a product whose cached reporting price goes more than 60 days without a successful catalog refresh is hidden rather than quoted to buyers on a stale price. In this case you already have ad-server pricing history — the fix is a working sync, not a pricing upload. When every hidden product is hidden for this reason, the products_available readiness blocker names the stale sync explicitly and its action opens the ad-server connection; a successful sync restores the pricing automatically. How to fix it.
  1. Open the diagnosis’s action — Upload pricing & availability for unresolved pricing, Fix pricing currency when every hidden product’s only problem is a currency mismatch, or Check ad-server connection when the only cause is stale ad-server-derived pricing.
  2. Upload a current pricing/availability feed, or connect ad-server pricing history, so buyers have a resolvable price for at least one product.
  3. If the cause is a currency mismatch, update the fixed price (or the feed) to your storefront’s settlement currency.
  4. If the cause is stale ad-server pricing, confirm the ad-server connection is healthy — the next successful sync refreshes the pricing on its own.
  5. The notification clears once at least one product is visible to buyers again.
Why this step exists. A storefront that’s live but selling nothing is worse than one that never went live — you’d have no signal otherwise. We tell you the moment your buyable catalog empties, not just when you happen to check readiness.

​
Media buy status can’t be confirmed

What it means. Your storefront routes buys through an ad-platform connection (Google, Meta, or another supported adapter), and we’ve repeatedly failed to confirm buy status directly with that platform. Buys already placed keep delivering on the platform itself — only the status shown here may be out of date until the connection recovers. Who fixes it. Usually nothing — most causes are a transient outage on our side or theirs, and the sync recovers automatically on its next attempt. If the connection has been down for a while, check that it’s still authorized. How to fix it.
  1. Open the diagnosis’s Check ad-platform connection action.
  2. Confirm the connection still shows as connected/authorized. If it’s been disconnected or your credentials expired, reconnect it.
  3. If the connection looks fine, no action is needed — the next successful sync clears this automatically.
Why this step exists. Without this signal, a dead connection would leave a buy showing “active” indefinitely with no way to tell it apart from one that’s actually confirmed and healthy.