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 Apostra 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. Apostra 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. Apostra 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. Apostra 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; Apostra does not invent a conversion.
  3. For FreeWheel, check that the execution currency on the source is the one you want to sell in. If a legacy source has no value, open its configuration, enter the currency FreeWheel will assign to insertion orders, and select Save execution currency. This does not replace or require the source’s write-only credentials. The currency must be one your storefront settles. Apostra 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). Apostra 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 have their own steps; see Testing an ad-server connection.
If the row says the currency contract is unavailable, retry the connection test. If it persists, contact Apostra; 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 Apostra 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.

​
FreeWheel booking readiness

What it means. A working FreeWheel login proves that Apostra can connect and read the network. Booking readiness is a separate check: Apostra creates an inactive, future-dated test placement with the same fields used for a media buy, reads those fields back, and removes the test objects. The source is commercially writable only when the complete check and cleanup pass. The source dashboard shows four states:
  • Certified means FreeWheel accepted the current booking contract and the test objects were cleaned up.
  • Not ready means the check found a specific field, permission, or cleanup problem. The diagnosis names the failed capability and correction.
  • Check expired means the evidence belongs to an older adapter or booking contract, or is older than the accepted validity period.
  • Not certified yet means no evidence has been produced. This is not the same as a failed check.
Who fixes it. The diagnosis tells you. A missing FreeWheel setting or permission is yours to correct. A cleanup or platform error appears as work for Scope3 and does not ask you to change credentials. How to fix a schedule-timezone failure.
  1. Read the failed schedule in the diagnosis: insertion order or placement.
  2. Use the exact timezone label supported by that FreeWheel schedule and the IANA timezone paired with it. Both values are required because FreeWheel’s label identifies the vendor setting while the IANA timezone preserves the intended instant through daylight-saving changes.
  3. When the FreeWheel network exposes supported values, choose from those values in setup. Do not type or guess a timezone label. If the network has no authoritative setting and no existing schedule to learn from, ask your FreeWheel operator to confirm one of the supported pairs shown by Apostra.
  4. Select Run booking check again. The diagnosis clears after the write, readback, booking transition, and cleanup all pass.
The dashboard also shows when the certificate ran, which adapter and request contract it covered, and whether cleanup passed. Talpa, Scripps, and every other FreeWheel network keep separate evidence; a value learned from one network is never reused for another. Why this step exists. Read access does not prove that FreeWheel will accept the complete media-buy payload. Running the controlled check during setup finds a missing schedule label or timezone before a buyer reaches the source.

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

​
Your GAM user can’t approve orders

What it means. Apostra creates each order in Google Ad Manager, but the GAM user it signs in as is not allowed to approve orders. GAM keeps those orders in draft, so a buy that was accepted does not deliver until someone approves the order. The diagnosis names your GAM network, and your Media Buys list shows the held buys as Held in your ad server, with the pending reason awaiting_ad_server_approval_permission. Apostra refuses a new listing until you fix this. Existing listings stay listed, and you can always unlist them. You see the problem on your setup checklist as Ad-server order approval, in your storefront health, in the source’s diagnostics, and as one open source health task per source until it is fixed. Three things can cause it:
  • No approve permission. The GAM role of the user lacks permission to approve orders.
  • No overbook permission. The role can approve orders, but not overbook, so GAM refuses to approve an order that exceeds the forecast availability.
  • An approval workflow that does not include the user. Your network requires orders to go through an approval workflow, and the user is not one of the approvers.
Who fixes it. You, or a GAM admin in your network. Only an admin can change roles and workflows in GAM. How to fix it. Either of these works:
  1. Ask a GAM admin to change what blocks the user:
    • Add permission to approve orders to the user’s GAM role, and permission to overbook as well if you sell guaranteed inventory.
    • Or, if your network uses an order approval workflow, add the user as an approver in that workflow.
  2. Or approve each held order yourself in GAM. Approving by hand also works, and the buy starts delivering once the order is approved. Do this for every order until the permission is fixed.
Apostra rechecks on its own, about every 15 minutes. The warning, the source health task and the Held in your ad server label go away at the next check after the permission is in place, and you do not need to confirm anything in Apostra. See Grant ad-server access for the base grant the user needs. GAM’s console labels change, so follow Google’s own support documentation for the exact menu names. Why this step exists. Apostra cannot approve an order for a user GAM does not trust to approve it, and it never raises its own permissions in your network. Your network decides who may approve orders, so the change has to come from you.

​
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. An operation on a sales agent you run is failing, so its inventory cannot sell until it works again. The diagnosis names the operation: usually product discovery (get_products), sometimes creative sync (sync_creatives). The agent may be unreachable, or it may answer but refuse our request: for example it speaks an older AdCP version, rejects a field we send, or its sign-in fails. A refusal of package assignments with UNSUPPORTED_FEATURE, recovery correctable does not count: Apostra sends the creatives again without the assignments. A sales agent source held for this reason goes live again on its own once the operation works. 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. Use the diagnosis’s Run discovery test action first: it shows the exact error your agent returned.
  2. Check that the agent is running and reachable at its registered endpoint URL, and that it supports the AdCP version and fields the error names.
  3. If the endpoint moved, update the source’s endpoint in the source setup surface.
  4. Run the discovery test again. It makes a read-only get_products call and clears the task only when that inventory operation completes successfully.
When the diagnosis names creative sync, the discovery test does not show that error. Fix how your agent answers sync_creatives; the next creative sync records a new reading. 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.

​
Source returned an AdCP error

What it means. Your agent answered a get_products call with a typed AdCP error, an adcp_error with a code and a message. The diagnosis names the code and what it asks for, and shows your agent’s own message unchanged in the technical details. Only codes in the AdCP standard set are recognized, and only from the error’s code; we never infer a code from the wording of a message.
  • AUTH_REQUIRED, AUTH_MISSING, AUTH_INVALID: authentication the request did not satisfy.
  • AUTHORIZATION_REQUIRED, PERMISSION_DENIED, SCOPE_INSUFFICIENT, READ_ONLY_SCOPE, FIELD_NOT_PERMITTED, AGENT_SUSPENDED, AGENT_BLOCKED: permission the identity on the request does not have.
  • ACCOUNT_REQUIRED, ACCOUNT_NOT_FOUND, ACCOUNT_SETUP_REQUIRED and the other ACCOUNT_* codes: an account that is missing or that your agent cannot use.
  • INVALID_REQUEST, VALIDATION_ERROR, CONFLICTING_SELECTORS: a request your agent found invalid.
  • RATE_LIMITED: a call rate your agent limits.
  • SERVICE_UNAVAILABLE: your agent reporting that it is temporarily unavailable.
  • VERSION_UNSUPPORTED: an AdCP version your agent does not support.
Any other standard code shows the code and its AdCP recovery class (transient, correctable or terminal). A code outside the standard set is not classified: the diagnosis says so and still shows your agent’s message. Who fixes it. It depends on the code, and the diagnosis does not decide that from the code alone. Read your agent’s message in the technical details first. How to fix it.
  1. Read your agent’s message in the diagnosis’s technical details.
  2. If it names a credential, permission or account, confirm the one stored for this source is the one your agent expects.
  3. Use the diagnosis’s Run discovery test action to confirm your agent now completes get_products.
Why this step exists. A typed error is the clearest signal your agent can give about what it needs. Naming the code, instead of reporting an error we could not classify, points you at the right part of your agent first.

​
Our request broke the Source’s capabilities

What it means. The request we sent your agent contradicts what your agent declared in get_adcp_capabilities, so a rejection is the answer the contract calls for. We compare four declarations: media_buy.buying_modes (an absent list reads as brief only, as AdCP specifies), account.required_for_products, account.require_operator_auth, and adcp.supported_versions (compared by major version, because a seller downshifts within a major). The diagnosis names what we sent and what you declared, for example buying_mode "wholesale" sent to an agent that declares only brief and refine, or no account sent to an agent that requires one. It is shown only when we hold capabilities your agent declared, never ones we filled in after a failed read. Who fixes it. Apostra. The diagnosis names Apostra as the owner and gives you no task, because the request is ours. The exception is capabilities that are out of date: if you changed a declaration recently, the diagnosis can reflect the older one until we refresh it. How to fix it. Nothing is needed from you in the usual case. If your declarations changed, refresh your agent’s capabilities and use the diagnosis’s Run discovery test action; if the diagnosis persists against current capabilities, contact Apostra support with the diagnosis text. Why this step exists. Blaming your agent for rejecting a request it said it would reject sends you to fix something that is not broken.

​
Public catalog marked account-specific

What it means. We asked your agent for its wholesale catalog without a buyer account, and it answered with cache_scope: "account". AdCP requires cache_scope: "public" whenever a get_products request carries no account, so we can’t cache that answer for every buyer. The diagnosis shows the code ACCOUNT_CACHE_KEY_MISSING. Your agent is reachable; this is a protocol problem, not an outage. Who fixes it. You, in your agent’s get_products handler. How to fix it.
  1. When a get_products request has no account, return the catalog every buyer can see and set cache_scope: "public".
  2. Return cache_scope: "account" only when the request named an account and the catalog depends on it.
  3. Nothing else is needed. We retry the catalog refresh about every 15 minutes, and the first one that succeeds clears this diagnosis.
This check only applies to agents that publish a wholesale catalog. If your agent builds products for each brief instead of publishing a catalog, we don’t refresh a catalog from it, and an earlier result of this check is cleared automatically. Why this step exists. We use your public catalog to show your products to buyers and to check that they are ready to sell. Until we can cache it, buyers may not see your products.

​
Our signed requests rejected

What it means. Your agent returned HTTP 401 to a request we signed with our AdCP request-signing key. The diagnosis shows your agent’s own reason: its request_signature_* error code when it sends one, otherwise the text of its response (code signed_request_rejected). A request_signature_* code means its signature check failed. Without one, read the reason: a 401 can also mean your agent rejected the credential configured for this source. Who fixes it. You, in your agent’s signature verifier. How to fix it.
  1. Read the reason in the diagnosis. Most failures are in key discovery: the verifier could not find our signing key.
  2. Resolve our key from our agent URL, https://api.apostra.com, not from the operator or brand on the request’s account. See Verifying our signed requests.
  3. Use the diagnosis’s Run discovery test action to confirm your agent now accepts our signed get_products.
Why this step exists. Your agent requires our signature on these operations, so until it can verify that signature, it rejects every request we send it for them, and buyers get no inventory from it.

​
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). Pricing data is guidance, so your products stay on the market: buyers can still bid on your auction products, but see no floor or price guidance for them until a current feed is uploaded. This warns you; it never takes you off the market or blocks going live. 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. Buyers see your pricing guidance again as soon as the feed is current.
See Wholesale avails and pricing for the file format and freshness window. Why this step exists. Buyers bid better against current guidance, and an old feed no longer describes your inventory. We stop showing guidance we can no longer stand behind, and leave the decision to bid with the buyer.

​
Wholesale pricing expiring soon

What it means. The wholesale pricing you uploaded starts expiring within 7 days. A feed expires on the earliest end date among its rows, or 365 days after you uploaded it, whichever comes first. Your products are still on the market, and they stay there after the date; this is notice before their pricing guidance lapses. Who fixes it. You. The pricing feed is produced by your side. How to fix it.
  1. Export a current wholesale pricing file with end dates past the date in the notice.
  2. Open the diagnosis’s Upload wholesale pricing action and upload the file before that date.
If the date passes without a new upload, the products priced by the expired rows stay listed as auction products with no floor and no price guidance, and this diagnosis becomes Wholesale pricing out of date. Why this step exists. A week’s notice lets you refresh pricing before buyers lose your guidance, instead of finding out after they have.

​
Some wholesale products have no eligible ad-server pricing

What it means. Apostra 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.

​
Product creative formats not defined

What it means. Your agent returned products whose only creative formats are format_ids that the creative agent they name does not define, for example video_320x480 under https://creative.adcontextprotocol.org. Apostra cannot map those ids to an AdCP canonical creative format, so a buyer’s creative cannot be matched to those products and its sync is refused. The finding lists up to five of the products and their format ids in unresolvableCreativeFormats. Declaring only legacy format_ids is still supported: a product is listed only when none of its formats can be mapped. Who fixes it. You, or whoever runs your agent. Only the agent can correct its own product declaration. How to fix it. For each named product, do one of the following:
  1. Declare formats the named creative agent defines, such as a standard format from https://creative.adcontextprotocol.org.
  2. Define each id in your agent’s list_creative_formats, with the canonical kind it maps to, so Apostra can map it.
  3. Declare the product’s format_options directly with a canonical format_kind and its params.
The finding clears when the next catalog refresh stores the corrected products. Why this step exists. A buyer’s creative names a canonical format. If none of a product’s formats maps to one, there is nothing the creative can be matched to, so the buyer finds out only when the creative sync fails.

​
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 Apostra 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. Apostra 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. Apostra 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 an Apostra-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 Apostra 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; Apostra 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. Apostra 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 Apostra.
  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 Apostra 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 Apostra 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 the products carry no pricing option buyers can use, an operator fixed price is set in a different currency than your storefront’s settlement currency, or ad-server-derived pricing went stale. Missing or expired pricing guidance does not hide a product that has an auction option. 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.