Magnite

Use this guide to configure Magnite bidding in CloudX.

Keep using the platform integration guides for SDK installation and ad loading:

• Android integration guide
• iOS integration guide
• Unity integration guide

Magnite can bid on your inventory through two paths. Choose one path for each app before you start the setup.

Choose an integration path

• Use the SDK path if your app already includes the CloudX Magnite adapter, or if you need Magnite native ads (beta).
• Use the SDK-less path if you cannot add the Magnite SDK to your app.

Both paths need approval from Magnite. Contact your Magnite rep before you start. Your rep creates the Site ID and Zone ID for each path. One Site ID and one Zone ID can apply to all your apps and ad units; only the SDK and SDK-less paths need different ones.

SDK path

For platform-specific Magnite adapter requirements, see:

• Android Magnite Adapter page
• iOS Magnite Adapter page
• Unity Magnite Adapter page

Overview

Use the following values:

• Account ID in the CloudX app-level Magnite mapping
• Site ID in the CloudX app-level Magnite mapping
• Zone ID in the CloudX ad-unit-level Magnite mapping
• CloudX app_key and CloudX ad unit identifiers in app code

CloudX collects Magnite bidder tokens internally, so you do not need to fetch Magnite bidder tokens in your app code.

Step 1. Complete Magnite-side setup and update app-ads.txt

1. Ask your Magnite rep to set up the SDK integration. Copy the Magnite Account ID. Magnite creates a new Site ID and a new Zone ID. You cannot create these IDs yourself, because Magnite must enable the SDK integration on its side.
2. Confirm with your Magnite rep that the zone accepts the sizes CloudX requests for each format: Banner 320x50, MREC 300x250, Interstitial 320x480 and 480x320, Rewarded video, and Native if you use native ads.
3. Complete any required Magnite review, app registration, and payout setup before expecting live demand.
4. Publish the matching app-ads.txt line for your Magnite Account ID:

rubiconproject.com, <ACCOUNT_ID>, DIRECT, 0bfd66d529a55807

Replace <ACCOUNT_ID> with your Magnite Account ID. Publish the line at https://yourdomain.com/app-ads.txt, where yourdomain.com is the developer website listed in the App Store or Google Play. Keep the existing entries for CloudX and other networks.

Magnite does not bid on apps whose app-ads.txt file is missing this line.

Step 2. Enable Magnite in CloudX

Go to Bidders, select Magnite, click Enable, then click Confirm.

If Magnite is disabled, CloudX will not request bids from Magnite even if your mappings are correct.

After enabling, you can enter your Magnite IDs from this same page: search for an app, select it, enter the Account ID and Site ID, enter the Zone ID for each ad unit under Placements, and click Save. You can also configure the same values from the app and ad-unit pages in the next steps.

Step 3. Configure your CloudX app

Go to Inventory -> Apps and create or open the app that matches your mobile application.

Add the following values to the Magnite mapping on the app:

If you have one Site ID for all your apps, enter the same value on each app.

Also copy the CloudX app_key from the app details page. Use the CloudX app_key in Android or iOS code. Do not use Magnite account or site IDs as the CloudX SDK app key.

Step 4. Configure CloudX ad units

Go to Inventory -> Ad units and add the Magnite mapping below for each eligible ad unit.

If you have one Zone ID for all your ad units, enter the same value on each ad unit.

Step 5. Add Magnite line items

Create line items for bidder Magnite on each CloudX ad unit where Magnite should compete.

• Use bidder Magnite
• Match the line item to the correct ad format
• Repeat the setup for each ad unit where Magnite should bid

Step 6. Finish app integration

Complete the integration and adapter setup for your platform:

• Android integration guide
• iOS integration guide
• Unity integration guide
• Android Magnite Adapter page
• iOS Magnite Adapter page
• Unity Magnite Adapter page

In app code:

• Initialize CloudX with the CloudX app_key
• Load ads using CloudX ad unit identifiers
• Do not pass Magnite Account IDs, Site IDs, or Zone IDs into app code
• For Interstitial and Rewarded ads, call show() only after the ad is ready

Step 7. Test and validate

1. Enable test mode for your device in CloudX.
2. Build and run the app with the CloudX app_key and the correct CloudX ad unit identifiers.
3. Request an ad from each mapped ad unit.
4. Confirm that the ad loads and that Magnite participates or wins where expected.

In test mode, CloudX requests bids with Magnite’s test placements instead of your IDs, and Magnite throttles test traffic, so not every test request fills. Test mode confirms the integration, not your Magnite IDs or Magnite’s approval. Validate those with controlled live traffic.

SDK-less path (BETA)

On the SDK-less path, Magnite is a server-side bidder: CloudX requests bids on the server and renders winning creatives with the CloudX SDK’s built-in renderer. There is no Magnite SDK or adapter to add to your app. The SDK-less path requires CloudX Android SDK 4.5.1 or newer and CloudX iOS SDK 3.8.0 or newer.

Magnite (CloudX rendered) is currently beta in CloudX. If it is not visible in the Bidders section, contact your CloudX account manager for beta access.

Supported ad formats

• Banner
• MREC
• Interstitial
• Rewarded

Native is not supported on the SDK-less path. Use the SDK path for Magnite native ads.

Step 1. Complete Magnite-side setup and update app-ads.txt

1. Ask your Magnite rep to set up the SDK-less integration. Your Account ID stays the same. Magnite creates a new Site ID and a new Zone ID for the SDK-less integration, separate from the SDK path’s IDs. You cannot create these IDs yourself, because Magnite must enable the SDK-less integration on its side.
2. Confirm with your Magnite rep that the zone accepts the sizes CloudX requests for each format: Banner 320x50, MREC 300x250, Interstitial 320x480 and 480x320, and Rewarded video.
3. Complete any required Magnite review, app registration, and payout setup before expecting live demand.
4. Publish the matching app-ads.txt line for your Magnite Account ID:

rubiconproject.com, <ACCOUNT_ID>, DIRECT, 0bfd66d529a55807

Replace <ACCOUNT_ID> with your Magnite Account ID. Publish the line at https://yourdomain.com/app-ads.txt, where yourdomain.com is the developer website listed in the App Store or Google Play. Keep the existing entries for CloudX and other networks.

This is the same line as on the SDK path. If your app-ads.txt file already has it, you do not need to change it.

Step 2. Enable Magnite (CloudX rendered) and add your Magnite IDs

Go to Bidders, select Magnite (CloudX rendered), click Enable, then click Confirm.

On the same Magnite (CloudX rendered) page, search for an app and select it. Enter the following values for each app and ad unit where Magnite should bid, then click Save:

If you have one Site ID and one Zone ID for all your apps and ad units, enter the same values on each.

The SDK-less bidder does not use the mappings you entered for the Magnite bidder. Enter your Account ID and the SDK-less Site ID and Zone ID for Magnite (CloudX rendered). Do not reuse the SDK path’s Site ID and Zone ID.

Step 3. Add line items

Go to Line Items and create line items for bidder Magnite (CloudX rendered) on each CloudX ad unit where Magnite should compete.

• Use bidder Magnite (CloudX rendered)
• Target Banner, MREC, Interstitial, or Rewarded ad units
• Repeat the setup for each ad unit where Magnite should bid

Step 4. Test and validate

1. Enable test mode for your device in CloudX.
2. Build and run the app with the CloudX app_key and the correct CloudX ad unit identifiers.
3. Request an ad from each mapped ad unit.
4. Confirm that the ad loads and that Magnite participates or wins where expected.

In test mode, CloudX requests bids with Magnite’s test placements instead of your IDs, and Magnite throttles test traffic, so not every test request fills. Test mode confirms the integration, not your Magnite IDs or Magnite’s approval. Validate those with controlled live traffic.

Switching paths

To move an app from one path to the other:

1. Ask your Magnite rep for the new path’s Site ID and Zone ID. Each path has its own Site ID and Zone ID; your Account ID stays the same.
2. Add the new bidder’s mappings to the app. Do not add its line items yet.
3. Remove the old bidder’s line items, then add line items for the new bidder.
4. Remove the old bidder’s mappings from the app.

Do not leave both bidders set up on the same app.

Troubleshooting

Magnite is not bidding

Check the following first:

• Your Magnite rep has completed setup for the path you use
• The bidder for your path is enabled in the Bidders section: Magnite for the SDK path, Magnite (CloudX rendered) for the SDK-less path
• The app has a valid Account ID and Site ID under that bidder
• The ad unit has a valid Zone ID under that bidder
• The Site ID and Zone ID are the ones Magnite created for your path; SDK and SDK-less IDs are different
• A line item for that bidder exists for the ad unit
• On the SDK-less path, the ad unit is not Native
• Your app-ads.txt file includes rubiconproject.com, <ACCOUNT_ID>, DIRECT, 0bfd66d529a55807 with your Magnite Account ID
• For iOS, the app is published on the App Store, so CloudX can look up the numeric App Store ID that Magnite requires

Magnite bids but the ad does not render

Check the following:

• Your app is using the CloudX app_key, not a Magnite identifier
• Your app is loading the intended CloudX ad unit
• The zone accepts the ad unit’s format and size
• On the SDK path on iOS, the requirements from the iOS Magnite Adapter page are complete
• On the SDK-less path, your app uses CloudX Android SDK 4.5.1 or newer, or CloudX iOS SDK 3.8.0 or newer

The mapping looks correct but loads still fail

Account ID, Site ID, and Zone ID must be present in the correct places under the bidder for your path. Re-check the app-level and ad-unit-level mappings in CloudX and make sure the values were copied exactly.

Both Magnite bidders appear in reports for the same app

The app is set up on both paths. Keep one path and remove the other bidder’s line items and mappings, as described in Switching paths.

Mapping Reference

Both bidders use the same fields. Values are stored separately for each bidder.