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 execution currency is not ready

What it means. The source is connected, but Interchange cannot prove that the currency the ad server will book is one your storefront can receive. The source remains visible, but its card says Not buyable and it is withheld from buyer requests. This is a transaction-safety block, not a cosmetic setup warning: a price and an ad-server order must never carry different currencies. The currency under test is the one your ad server itself reports booking in, not the default currency on your storefront. If your storefront settles in several currencies, an ad server that books in any one of them is ready — it does not have to match your storefront’s primary currency. An ad server that reports no booking currency at all is never ready, whatever your saved connection settings say. Who fixes it. Interchange repairs this on its own where the currency it would set is already proven — a Google Ad Manager limit when the network already books in a currency your storefront can settle, and a FreeWheel source’s own configured execution currency. A seller resolves a real currency mismatch: an ad server that books a currency the storefront cannot receive, or credentials that cannot read the ad server. Scope3 handles platform or vendor-observation failures. How to fix it.
  1. Open Inventory Sources. The source card and Ad-server execution currency setup row name the affected source and the exact failed check.
  2. For GAM, run Test connection once after granting access. Interchange reads the network currency from GAM and safely narrows the source to a currency your storefront can settle, keeping the one the network already books in when that works. If GAM and the storefront have no currency in common, change the storefront’s payout currency or use a GAM network that books in a supported currency; Interchange does not invent a conversion.
  3. For FreeWheel, check that the execution currency on the source is the one you want to sell in. Interchange reads the network and restates that currency to the ad server for you, within a quarter of an hour — or run Test connection on Sync & diagnostics to start it now. Two states need you: FreeWheel’s existing orders book a different currency (change the source’s execution currency to match, or use a network that books yours), and credentials that connect but cannot read insertion orders (reissue them with insertion-order read access). Interchange never picks the currency for you — FreeWheel stamps it on each order itself, so a guess would be booked as fact.
  4. SpringServe and AdsWizz remain unavailable for new live buys until their booking and currency readback path completes certification. A configured rate or default currency is not treated as vendor proof, and no repair makes those sources buyable.
If the row says the currency contract is unavailable, retry the connection test. If it persists, contact Scope3; the fleet monitor has raised the same source and issue code internally. Why this step exists. GAM reports an authoritative network currency. FreeWheel has no account-level currency field, so Interchange reads what FreeWheel books on the orders a network already holds and refuses any currency those orders contradict. A network holding no priced order has nothing to read; there, the currency on the source is carried to your first booking, where FreeWheel names its own choice, and a mismatch refuses that buy rather than selling at the wrong price.

​
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 we do not have the permission 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. The diagnosis tells you which of two situations you are in, because they need different actions:
  • “We don’t have reporting access from <ad server>, last checked <date>.” We asked your ad server and it declined. The date is when that answer was recorded — if it is old, the answer may be too, so re-check after any permission change.
  • “We haven’t been able to confirm reporting access with <ad server> yet.” We have not been able to complete the check at all, so we are not claiming your ad server refused anything. On FreeWheel this is usually because the check needs one delivering placement to read against, which only exists once a media buy has been trafficked through the source — see When the check cannot run yet.
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.

​
Delivery reports rejected

What it means. Your source is returning delivery reports, but they do not match the shape the AdCP delivery contract requires, so we refuse them rather than store numbers we cannot trust. Inventory, pricing, and orders are unaffected and the source keeps selling; only the delivery reporting for this source is incomplete. The diagnosis names the exact field that failed validation, for example:
Read that as a path into the payload your source returned from get_media_buy_delivery: the first media buy’s first package sent a delivery_status we could not accept. A value outside the AdCP enum and a null where a string is required are the two most common causes. Who fixes it. You, or whoever operates the sales agent. The payload comes from your source, so the correction has to happen there. Scope3 cannot rewrite a report into a valid shape without inventing data. How to fix it.
  1. Read the field path in the diagnosis. It points at the exact property to correct in your get_media_buy_delivery response.
  2. Check that property against the get_media_buy_delivery reference. Values outside a defined enum, and null in place of a required string, are rejected.
  3. Deploy the fix on your sales agent. The next scheduled poll picks it up and the diagnosis clears on its own; there is nothing to re-run here.
  4. If the diagnosis persists after your fix has shipped, open source diagnostics to confirm the newest poll is still being refused rather than reading an older result.
Why this step exists. Silently accepting a malformed report would put numbers you cannot rely on into billing and delivery views. Refusing it keeps the reporting you do see trustworthy, and naming the field means you can fix the cause instead of guessing from a generic failure.

​
Delivery reports not returned

What it means. We cannot retrieve delivery reports from this source at all, as opposed to retrieving a report we then refuse (Delivery reports rejected). Inventory, pricing, and orders are unaffected and the source keeps selling; only delivery reporting is unavailable. Who fixes it. It depends on who runs the source, and the diagnosis says which. For a source you operate, it is yours to fix. For a Scope3-managed source, the fix is ours and the diagnosis will say so rather than asking you to act. How to fix it. For a source you operate:
  1. Confirm your agent’s get_media_buy_delivery endpoint is reachable and returns a response for the media buys in question.
  2. Check that any credentials the reporting endpoint needs are still valid. Reporting can use different credentials from the ones inventory uses.
  3. Open source diagnostics to see the most recent attempt and its error.
Why this step exists. Reporting failing is different from selling failing, and it is worth telling apart from a source that is fully down. Your inventory keeps trading while this is open.

​
Forecasting access missing

What it means. FreeWheel accepted the base connection, but we do not have forecasting access for the API user. Inventory, orders, and selling are unaffected; forecast estimates are unavailable until this separate capability is provisioned. As with reporting, the diagnosis distinguishes “We don’t have forecasting access from FreeWheel, last checked <date>” (FreeWheel declined, on that date) from “We haven’t been able to confirm forecasting access with FreeWheel yet” (the check has not completed, so we are not saying FreeWheel refused). See When the check cannot run yet. 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.

​
When the check cannot run yet

What it means. Interchange confirms reporting and forecasting access on FreeWheel by reading delivery data for one of your placements. That needs a placement to read — which exists only once a media buy has been trafficked through the source. Until then the check cannot complete, and re-checking returns “a cached FreeWheel placement is required” rather than a verdict. This is why the diagnosis says we haven’t been able to confirm access rather than that FreeWheel refused it. We have not asked them yet. Who fixes it. Nobody, directly — it resolves once the source starts transacting. Asking FreeWheel to re-grant a permission will not clear it, because the permission is not what is blocking the check. How to move past it.
  1. Make sure at least one product on the source is priced and buyable — on FreeWheel that means uploading wholesale pricing or setting a fixed price, since FreeWheel does not expose pricing data to Interchange.
  2. Let a buyer transact, or run one media buy through the source yourself.
  3. Once a placement is delivering, select Access confirmed - re-check reporting. The check now has something to read against and returns a real answer — either access works, or FreeWheel has genuinely declined it.
Why this step exists. A permission we have never successfully tested is not the same as a permission that was refused, and telling you your vendor blocked something they were never asked wastes your time chasing the wrong party.

​
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.