> ## Documentation Index
> Fetch the complete documentation index at: https://docs.interchange.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshoot source problems

> What each source-health problem means, who fixes it, and exactly how

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](/v2/storefront/inventory-sources/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](/v2/storefront/inventory-sources/wholesale-avails-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](#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](#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](/v2/storefront/inventory-sources/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.