Skip to main content
This page is for a publisher that runs its own ad server, usually Google Ad Manager (GAM), and has no sales agent of its own. It follows one example from signup to a first booking: a Turkish news site on GAM that a Dutch buyer has invited, because the buyer wants the site’s inventory targeted to the Netherlands. You can follow it yourself in the Apostra web app, or hand it to your own agent. Each step names the page that has the detail. Steps 1 to 6 are yours. Step 7 is work Apostra does, and it can stop a first booking until it is done. Apostra publishes no timings for it. The signup link for a publisher is https://app.apostra.com/signup?intent=storefront. With intent=storefront the page opens on the media-company path and is titled “Open your Storefront”. The plain link, https://app.apostra.com/signup, asks how the company will use Apostra, and it is the one Apostra’s website uses. A buyer who wants a publisher on Apostra can invite a seller by sending the publisher that signup link with a short sentence about why. Sending the link contacts nobody on the buyer’s behalf, and it does not tell Apostra or the seller that the buyer wants them. To keep the publisher on the buyer’s list, the buyer records a supply request for the publisher’s domain and channel, from the Media Partners page or by asking Murph. A supply request is the buyer’s own record of demand. It does not invite, nudge or notify the seller. The publisher still has to sign up for itself, as step 1 describes.

​
What you need before you start

  • A work email address on your company’s domain. Signing up to sell needs one, and a personal address such as a free webmail account is not accepted for it.
  • A GAM network, and someone with the rights in GAM to add a user and give it a role (see step 4).
  • The currency you want to be paid in, chosen from the currencies Apostra can settle (see step 3). Turkish lira is not one of them.
  • A list of the countries and channels you want to sell to, including countries where your readers live but you do not (see step 3).

​
Step 1: sign up with your work email

Choose the option to sell inventory and sign up with your work email. Apostra creates a Seller Account. If your email domain already has an organization on Apostra, you need an invitation from that organization to sign up. Ask the person who set it up to invite you.

​
Step 2: check your account type

A Seller Account is a Listing or a Storefront. Read yours with get({ "kind": "seller" }), which returns sellingMode. Account type is the full rule. What matters for a publisher with no sales agent of its own:
  • Listing means you bring your own sales agent, or use a third party’s. Apostra lists your products and does not host an agent for you.
  • Storefront means Apostra hosts the agent that answers buyer briefs for you.
Setting up an ad server that Apostra manages for you is Storefront setup. When that setup has to create your storefront, it records the Storefront type. It does not change the type of an account that already has one. So if you are a publisher with an ad server and no agent of your own, read sellingMode and, if it says listing, ask a direct administrator of your organization to switch it with save_seller({ "sellingMode": "storefront" }). The Apostra-hosted agent is what a Storefront is. A Storefront needs a plan that covers it. If yours does not, the switch is refused with CONFLICT and the reason says what to do next. Pricing by account type has not taken effect yet, so the switch does not change what you are billed today. The signup screen’s Listing option says it “includes your connected sales agent”. Read that as an agent you connect yourself. It does not mean Apostra provides one.

​
Step 3: set your payout currency and your markets

Both of these decide who can buy from you, so set them before you build products. Payout currency. Apostra settles in these currencies: USD, EUR, GBP, JPY, CHF, CAD, AUD, NZD, CNY, HKD, SGD, SEK, NOK, DKK, PLN, KRW, INR, MXN, BRL and ZAR. Local currencies outside that list, such as Turkish lira (TRY), are not accepted. Send defaultCurrency and paymentCurrencies to save_seller, and include the default in paymentCurrencies. A product shows to buyers only if it has a price Apostra can use. A product priced only in a currency that is not one of your settlement currencies stays hidden. A product with no pricing option at all stays hidden too. Setup checklist and go-live has the full rule. Your ad server’s own currency matters as well. If your GAM network books in a currency that none of your settlement currencies matches, the source is withheld from buyers until you change your payout currency or use a network that books in a supported one. Apostra does not invent a conversion. See ad-server execution currency. Markets. A buyer request that names countries or channels outside your markets never reaches you. In the example, if you save only Turkey, the Dutch buyer’s request for the Netherlands is never sent to your sources. If your readers include people living abroad, add those countries, or accept every country with acceptsAllCountries: true. If you set no countries, requests from every country reach you. Save channels and countries together in one save_seller call. Markets has the rule and the country groups.

​
Step 4: connect Google Ad Manager

Call save_inventory_source with only adServer:
The call creates nothing. It opens the Connect ad server form and returns serviceAccountEmail, the email of a service account Apostra creates for your organization. Credentials are entered in the form and never pass through chat.
  1. In GAM, add serviceAccountEmail as a user in your network.
  2. Give it a role that can read inventory, traffic orders and line items, and approve orders. Apostra recommends the Administrator role. A custom role with trafficking and order approval works, and so does adding the user as an approver in your order approval workflow. The built-in Trafficker role cannot approve orders.
  3. Enter your network code in the form.
The person who does step 1 therefore needs rights in GAM to add users and assign roles. If the GAM user cannot approve orders, a new listing on Apostra is refused until the permission is corrected. Connecting an ad server covers the form, and Ad server access lists the roles that cannot approve orders and how to fix the permission.

​
Step 5: verify your brand domain

Buyers see your brand domain as who they are dealing with. An unverified brand domain blocks go-live. It appears as the operator_domain check in your setup checklist. If your brand domain is the domain you signed up with, you verify that domain once. Any one of these works: an active member of the account with an email address on the domain, a DNS TXT record that Apostra reads directly from DNS, or a manual review by Apostra for when neither of the first two is possible. If your brand domain differs from your registered domain, you also publish evidence that links the two. Which domain is which has the record name and value and the steps.

​
Step 6: create your products

A product is what a buyer sees and books. Create products from your synced ad-server inventory with save_wholesale_product, passing the sourceId of your GAM source. Save a product with status: "active" when it is ready, because a draft is hidden from buyers. Give each product a price in one of your settlement currencies. Product creation has the fields and the refusals.

​
Step 7: what Apostra does before buyers can find you and book

Two steps belong to Apostra, and your setup checklist can stay open until each one is done.
  • Marketplace review. A new storefront starts as PENDING_REVIEW. You can configure and use it, but it does not appear in public buyer discovery until Apostra reviews it and lists it (LISTED).
  • Ad-server go-live certification. For a GAM source Apostra manages, a no-spend check that a booking works must pass before buyers can book. Until it does, buyers can still find your products and plan with them. Your checklist lists it as esa_go_live_certification, named “Ad-server go-live certification”. Apostra’s setup logic describes these checks as no-spend certifications that the managed ad server runs, and there is nothing for you to enter. The checklist entry can link to Run go-live certification.
If either step stays open and you are waiting on it, ask your Apostra contact. Apostra does not promise a time for either.

​
Step 8: billing and payout

Accepting the Terms, how you pay Apostra and where you are paid are set in Plan & Billing. A person does this in the Page: payout details are never written by an agent call, and bank details are typed into the Page and do not pass through the model.

​
Step 9: check the go-live checklist

Call get({ "kind": "seller", "include": ["readiness"] }). readiness.goLive.state is setup until every required step is complete, and goLive.progress.nextStepId names the next one. The setup checklist lists every check, what blocks going live, and the difference between that state and whether buyers can use you right now. For the second question, call the status tool.

​
Your first booking

When your checklist reads live and Apostra has listed you, a buyer’s agent can send you a brief, see your products and book one. For a managed ad server the booking becomes an order in your GAM network. Depending on your media-buy approval setting, a buy can wait for you to approve it, and if GAM needs the order approved by someone else, Apostra creates an action item and completes it once the order is active in GAM. The Media Buys Page is where you see each buy and whether anything is wrong with it.