Understanding Stored Requests in Prebid Server (Java): A Guide for Publishers and Ad Ops

Managing complex header bidding configuration can be a thorn in the side for publishers, especially at scale. Passing extensive bid parameters on every auction request not only increases page weight but can make troubleshooting, updates, and onboarding partners a logistical nightmare.

Prebid Server’s stored requests feature addresses this problem by allowing you to centralize and reference auction configurations—from banner size to bidder details—without constantly sending bulky JSON with each call. This post breaks down how stored requests work in Prebid Server (Java), why they matter, and how you can use them to streamline your stack.

What Are Stored Requests in Prebid Server?

Stored requests are preconfigured blocks of auction data—ranging from full OpenRTB requests to specific impression (imp) objects—that live server-side. Instead of passing every configuration detail in each auction request, clients can reference a stored request by its ID, reducing request size and enabling easier configuration changes.

Impression-level vs. Top-Level Stored Requests

– Impression-level stored requests: Scoped to individual ad slots (imp objects). Useful for defining parameters unique to a particular placement (e.g., banner size, bidder configuration for a specific ad unit).
– Top-level stored requests: Apply to the entire auction payload. Ideal for global settings like timeout (tmax), targeting information, or price granularity. Do not store full imp objects here—stick to auction-wide configs.

Example: You might store a 300×250 banner unit’s targeting and bidder settings as an impression-level stored request, while using a top-level stored request to define a network-wide timeout or price granularity.

How Stored Requests Simplify Header Bidding Flows

Leveraging stored requests changes how publishers interact with both Prebid.js and Prebid Server (PBS). Instead of transmitting full imp and bidder details from the client, you send lightweight requests referencing server-side configurations by ID.

Workflow Example

1. Publisher defines a stored request (e.g., ‘banner-slot-1’) describing the ad size and bidders in a server-side file or database.
2. On the page, Prebid.js or your wrapper sends only the necessary IDs to Prebid Server.
3. Prebid Server merges stored details into the auction, executes the bidding process, and returns bids.

This model saves bandwidth, centralizes updates, and allows for scalable management: change a bidder in one place, and it’s live across all pages referencing that stored request.

Partial Stored Requests and Overrides

Stored requests do not need to be complete objects. For example, you can store the core configuration for an imp, then have client-side requests fill in values like the impression ID at runtime. If there’s a conflict (e.g., both the stored request and HTTP request specify a value), the HTTP request version wins. This simplifies customizing behavior for specific pages without redundant config bloat.

Backend and Update Methods: Files, Databases, and HTTP APIs

Prebid Server (Java) supports a variety of storage backends for stored requests, giving publishers flexibility based on operational needs.

Backend Options

– **File system**: Fastest to set up for small deployments or testing. Store JSON files in a directory on your PBS server.
– **Database (Postgres/MySQL)**: Scale safely by centralizing and versioning stored requests. Typical for mature publishers and networks.
– **HTTP Endpoint**: Fetch stored requests from a remote API. Useful for dynamic or multi-region environments, but can be less performant.

You can also mix these (e.g., default to database, fallback to HTTP) for migration or redundancy.

Real-World Configuration Example

To set up a Postgres backend with local caching and remote update listening, configure:
– Database connection details and queries
– In-memory LRU cache size and refresh rate
– HTTP polling for updates

This lets you quickly serve popular stored request IDs and keep configurations fresh during rollouts or rapid changes.

Best Practices, Pitfalls, and Advanced Use Cases for Publishers

Stored requests offer efficiency and control, but come with important nuances for ad ops teams.

Operational Guidelines

– Never place imp objects in top-level stored requests—keep auction- and impression-level configs separate for clarity.
– Use partial stored requests for base configs; override as needed for unique page or campaign requirements by specifying differences in the client request.
– Remember, stored request merges are not recursive: if a stored request references another stored imp ID, it won’t be auto-resolved.
– Use version control (especially with file- and DB-based backends) to track changes to stored request data.

Troubleshooting and QA

– If an auction behaves unexpectedly, check which stored request IDs were passed and what values are stored on the backend.
– Use caching with short TTLs during rapid testing; increase TTLs in stable environments for performance.
– Audit both your request inputs and stored data for accidental drift: misaligned config between code and stored requests is a leading source of problems in production.

What this means for publishers

Stored requests fundamentally streamline header bidding management for publishers. They drive consistency across sites, accelerate onboarding of new demand partners or ad units, and reduce fragility from client-side configuration errors. At scale, this translates to higher reliability, faster page loads, and more strategic control over auction parameters and troubleshooting. By thoughtfully separating global and impression-level configs, publishers gain a modular system that supports both granular overrides and global defaults.

Practical takeaway

For publishers, adopting stored requests in Prebid Server (Java) is a practical way to maintain clean, auditable, and scalable header bidding setups. Start by moving your stable, unchanging configs into stored requests, referencing them by ID from Prebid.js or server calls. Use partial stored requests and HTTP overrides for flexible, page-specific tweaks, but keep core settings in one server-side place for easier QA and updates.

If you’re running multiple sites, or regularly change partners or ad unit settings, set up a proper backend (database or HTTP) and enable local caching to balance performance with up-to-date configurations. Always plan for change: use versioning, test overrides, and periodically audit both stored data and real auction requests to catch misconfigurations early. This approach keeps your ad stack manageable as your header bidding program grows.