> For the complete documentation index, see [llms.txt](https://support.gamoshi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.gamoshi.com/gamoshi-wiki/faq.md).

# FAQ

## General Infrastructure and Operations

<details>

<summary>Where Are Gamoshi’s Data Centers Located?</summary>

Gamoshi’s infrastructure is distributed across the following locations:

* **Google Cloud Storage:** Berkeley County, South Carolina.
* **Amazon Web Services:**
  * US East 2—Ohio.
  * Frankfurt—Europe.
  * Singapore—APAC.

</details>

<details>

<summary>What Is the Maximum Bidding QPS per Data Center?</summary>

Each regional data center supports up to 100,000 bidding queries per second.

</details>

<details>

<summary>Which Media Types and Environments Are Supported?</summary>

Gamoshi supports the following media types:

* Native.
* Banner.
* Video, including CTV and OTT.
* Audio.

These media types are supported across desktop, mobile web, and in-app environments.

</details>

<details>

<summary>Which Integration Protocols Are Supported?</summary>

Gamoshi supports:

* OpenRTB 2.0–2.6.
* JSON.
* Protobuf.
* Regular tags.
* VAST 2.0–4.0.
* VPAID tags.
* Server-Side Header Bidding.
* Client-Side Header Bidding.
* Mobile Header Bidding.

</details>

<details>

<summary>Which Server-Side Solution Does Gamoshi Use?</summary>

Gamoshi uses a proprietary implementation built on Prebid Server.

</details>

<details>

<summary>Which Fraud Detection and Media Quality Tools Are Used?</summary>

Gamoshi uses Pixalate for anti-ad-fraud and media quality protection.

</details>

<details>

<summary>Which Database Service Is Used for IP-Based Location Targeting?</summary>

Gamoshi uses MaxMind for IP-based geographic location services.

</details>

<details>

<summary>What Is Gamoshi’s TAG ID?</summary>

Gamoshi’s corporate TAG ID is:

`20e30b2ae1f670f2`

</details>

<details>

<summary>Which Currencies Are Used for Bidding and Billing?</summary>

All bidding and financial billing processes use USD.

</details>

<details>

<summary>How Can Reporting Be Accessed?</summary>

Reporting is available through:

* Dashboard access.
* Automated daily reports delivered by email in Excel format.
* Direct API integration.

All performance data is recorded in the UTC time zone.

</details>

<details>

<summary>Does Gamoshi Support Private Marketplace Deals?</summary>

Yes. Private Marketplace deals are supported.

</details>

## Programmatic Real-Time Bidding Specifications

<details>

<summary>Which OpenRTB Fields Are Mandatory in a Bid Response?</summary>

Gamoshi follows the standard OpenRTB specifications. No additional mandatory fields are required outside the official specification.

</details>

<details>

<summary>Are There Custom Requirements Outside the OpenRTB Specification?</summary>

No. The platform does not require a custom bid request or response structure beyond the OpenRTB standard.

</details>

<details>

<summary>What Is the Default Maximum Request Timeout?</summary>

The maximum request timeout is approximately 300 milliseconds.

</details>

<details>

<summary>What Is the Expected Response Time?</summary>

Response times generally range from 100 to 400 milliseconds, depending on the Supply Partner’s request and the other participants in the auction.

</details>

<details>

<summary>Which Payloads and Data Formats Are Supported?</summary>

Gamoshi supports:

* JSON payloads.
* Gzip-compressed JSON for bid requests and bid responses.

</details>

<details>

<summary>Are Multiple Impressions Supported in a Single Bid Request?</summary>

No. Multiple impressions within a single bid request are not supported.

</details>

<details>

<summary>Are Custom ext Fields Supported in Bid Requests?</summary>

Yes. Custom extension fields within bid requests are supported.

</details>

<details>

<summary>Are Recommended OpenRTB Attributes Treated as Required?</summary>

No. Attributes defined as recommended in the OpenRTB specification are not treated as mandatory.

</details>

<details>

<summary>Are First-Price and Second-Price Auctions Supported?</summary>

Yes. Gamoshi supports both First-Price and Second-Price auctions.

</details>

<details>

<summary>Are Auction Price Macros Replaced Within the ADM?</summary>

Yes. The platform replaces auction price macros within the creative markup provided in the `adm` field.

</details>

<details>

<summary>Are Creative Responses Scanned?</summary>

Gamoshi performs a minimal technical validation to confirm that the protocol requirements have been met.

The platform also performs automated domain filtering against the Advertiser’s Block Lists.

</details>

<details>

<summary>Can Invalid Bids and Their Reasons for Failure Be Tracked?</summary>

Yes. Reporting and tracking mechanisms identify the reasons for invalid bids.

</details>

<details>

<summary>Is the imp.banner.format Object Supported?</summary>

Yes. The `imp.banner.format` object is supported. However, explicitly specifying the width and height remains preferred.

</details>

<details>

<summary>Is the OpenRTB metric Object Supported?</summary>

No. The standard OpenRTB `metric` object is not supported.

</details>

<details>

<summary>Are bapp and source.tid Supported?</summary>

Yes. Both the blocked Advertiser application parameter, `bapp`, and the source transaction ID, `source.tid`, are supported.

</details>

<details>

<summary>Can a Partner Buy Inventory Using Multiple Seat IDs?</summary>

Yes. Buying through multiple Seat IDs is supported.

</details>

<details>

<summary>Which Response Is Expected for a No-Bid?</summary>

Gamoshi expects and returns an HTTP 204 No Content response for a no-bid.

</details>

## Auction Workflow and Impression Tracking

<details>

<summary>How Does the Ad-Serving Auction Work?</summary>

Gamoshi sends requests concurrently to all eligible Advertisers, providing them with an equal opportunity to participate in the auction.

First-Price or Second-Price auction clearing is applied according to the Supply Partner’s requirements. A server-side win notification is then sent.

</details>

<details>

<summary>How Are Impressions Counted and Billed?</summary>

The billable event depends on the media type, environment, and integration:

| **Media type or environment** | **Impression tracking method**                                                                                                         |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| In-App and Site Banner        | An image pixel is injected into the ADM and triggered when rendering begins. The impression or MRAID impression is the billable event. |
| Native                        | An image pixel is injected into the ADM and triggered when rendering begins. The impression is the billable event.                     |
| Video                         | Tracking pixels are injected into the VAST XML. The video start event is the billable event.                                           |
| In-App MRAID Interstitial     | An explicit MRAID impression event is recorded as the billable event.                                                                  |
| OpenRTB 2.5 or higher         | A standard Billing Notice URL, `burl`, is triggered and registered.                                                                    |

</details>

<details>

<summary>Is the NURL Impression Notification Method Supported?</summary>

Yes. Notice URLs, or `nurl`, are supported for impression notifications.

</details>

<details>

<summary>How Is Impression Expiration Handled?</summary>

When an Advertiser includes an explicit impression expiration time in the bid response, Gamoshi forwards that duration to the Publisher.

If the Advertiser does not specify an expiration time, the default is 45 minutes.

For operational context, the following caching-delay benchmarks are used:

| **Environment**                           | **Caching delay**    |
| ----------------------------------------- | -------------------- |
| Desktop and Mobile Web Browsers           | 1 minute             |
| Cached Mobile App Banner Ads              | 5 minutes            |
| Cached Mobile App Native Ads              | 10 minutes           |
| Mobile and Video Interstitials            | 30 minutes or longer |
| Audio or Video with Server-Side Stitching | Very long or unknown |

</details>

## Connected TV Specifications

<details>

<summary>Which Macros Are Required for CTV VAST Endpoints?</summary>

CTV VAST endpoints must use the applicable query parameters.

</details>

### Baseline VAST Query String

`https://rtb.gamoshi.io/r/{partner_id}/bidr?adtype=video&rformat=vast_xml&cb=[CACHEBUSTER]&adw=[ADW]&adh=[ADH]&bidfloor=[BID_FLOOR]&lat=[LAT]&lon=[LON]&dnt=[DNT]&app_name=[APP_NAME]&app_store=[APP_STORE_URL]&app_ver=[APP_VERSION]&device_make=[DEVICE_MAKE]&device_model=[DEVICE_MODEL]&device_os=[DEVICE_OS]&device_osv=[DEVICE_OS_VERSION]&app=[APP_ID]&app_bund=[APP_BUNDLE]&ifa=[IFA]&ctv=true`

### Optional Video Parameters

The following parameters can be appended to define video duration and bitrate limits:

`&v_minduration=[VIDEO_MIN_DURATION]`

`&v_maxnduration=[VIDEO_MAX_DURATION]`

`&v_minbitrate=[VIDEO_MIN_BITRATE]`

`&v_maxbitrate=[VIDEO_MAX_BITRATE]`

### Privacy and Regulatory Parameters

Use the following parameters when applicable:

| **Requirement** | **Parameters**                  |
| --------------- | ------------------------------- |
| GDPR            | `gdpr=[GDPR]&consent=[CONSENT]` |
| COPPA           | `coppa=[COPPA]`                 |

### Server-Side Requests

If the VAST request is initiated through a server-side proxy rather than directly from the client device, pass the client’s original IP address using:

`request_ip=[IP]`

## Identity Resolution and Cookie Syncing

<details>

<summary>Can Gamoshi Host User-Matching Tables and Initiate User Syncs?</summary>

Yes. Gamoshi can host the master user-matching table and initiate user synchronization loops.

</details>

<details>

<summary>How Does Cookie Sync Integration Work?</summary>

The synchronization process is bidirectional:

* Gamoshi can receive and map an external Partner’s User IDs.
* A Partner can receive and map Gamoshi’s internal User IDs.

</details>

<details>

<summary>What Is the Maximum User-Syncing QPS?</summary>

Cookie-syncing volume scales dynamically and is limited to approximately 5%–10% of the Partner’s relevant operational QPS.

</details>

## iOS 14+ and SKAdNetwork Support

<details>

<summary>Does Gamoshi Support Apple SKAdNetwork?</summary>

Yes. Gamoshi processes the `BidRequest.imp.ext.SKAdNetwork` extension object and returns the required signed parameters to downstream SSP and SDK layers.

This supports ad signatures and the routing of conversion postbacks to endpoints registered with Apple.

</details>

<details>

<summary>Can Requests Without the Buyer’s SKAdNetwork ID Be Filtered?</summary>

Yes. Incoming requests can be filtered when they do not contain the Buyer’s valid SKAdNetwork ID.

</details>

<details>

<summary>Which Identifier Is Used When IDFA Is Unavailable?</summary>

Gamoshi uses the Identifier for Vendors, or **IDFV**, as the primary fallback identifier.

</details>

<details>

<summary>Which OpenRTB Field Contains the IDFV?</summary>

The IDFV is passed in:

`device.ext.ifv`

</details>

<details>

<summary>How Are Frequency Capping and Invalid Traffic Filters Applied Without Tracking Consent?</summary>

When explicit user-tracking consent is unavailable, frequency capping and Invalid Traffic filters are calculated using the IDFV.

</details>

<details>

<summary>Can Gamoshi Process Requests Without an IDFA?</summary>

Yes. In environments without an IDFA, requests are sent with the zeroed-out string pattern `000.000` in place of the standard IDFA value.

</details>

<details>

<summary>Does Gamoshi Provide an Exchange User ID?</summary>

Yes. Gamoshi provides a User ID specific to the source application and exchange-partnership combination.

The value is populated in the OpenRTB `user.id` field:

* IDFA is used when available.
* IDFV is used when IDFA is restricted.

</details>

<details>

<summary>Does Gamoshi Enrich Bid Requests?</summary>

Yes. When the information is available from the supply stream, Gamoshi enriches incoming bid requests with additional contextual data and hardware device signals.

</details>