Understanding Stored Requests in Prebid Server: Practical Guidance for Publishers
For publishers managing header bidding across multiple channels, configuration and scale can quickly become overwhelming. Hardcoding demand partner details or auction parameters in every app release or AMP template is not only time-consuming, but also limits flexibility and rapid optimization.
Prebid Server introduces the concept of Stored Requests to help publishers solve these headaches. By centralizing OpenRTB configuration management, publishers can enable more agile monetization setups across mobile apps and AMP environments, with fewer code changes and less operational risk.
What Are Stored Requests in Prebid Server?
Stored Requests are blocks of OpenRTB JSON configuration saved centrally—outside of your website, app, or AMP template. When an auction request comes in, Prebid Server fetches and merges these stored parameters on the server-side before sending out the final OpenRTB request.
This setup allows you to adjust auction logic, add or remove bidders, and tweak parameters without touching the client-side code or deploying new app versions.
How It Works: The Basics
A client (Web, App, or AMP) sends a ‘skeleton’ OpenRTB request containing only essential identifiers such as a Stored Request ID. Prebid Server then looks up relevant configuration blocks (stored in a database or local files) and assembles the complete OpenRTB payload by merging stored blocks with the skeleton. The completed request is then processed normally, as if all parameters were supplied upfront.
Stored Requests for Mobile Apps: Reducing App Dependency
Mobile apps face unique operational challenges—hardcoding bidders, ad units, or parameters can mean every optimization requires a new app release. Stored Requests solve this by allowing you to externalize key auction configurations.
App Implementation Flow Example
1. The mobile SDK sends a very minimal OpenRTB structure, omitting bidders and most targeting info.
2. Prebid Server fetches both top-level and impression-level stored requests by their respective IDs.
3. These stored blocks insert the necessary bidder details, parameters, and targeting directly before firing off the auction—no app update required.
For example, when a new bidder needs to be added, you update the stored JSON in Prebid Server’s database. The next app auction immediately reflects this change—no user action or app store release needed.
Stored Requests in AMP: Centralizing and Streamlining
AMP (Accelerated Mobile Pages) restricts how much auction configuration you can supply client-side. Stored Requests unlock server-side flexibility, letting you manage most auction parameters centrally and fine-tune per-page details via URL parameters.
AMP Flow Example
In a typical setup, each AMP ad unit is mapped to a Stored Request using its tag_id. When an AMP page loads, the request to Prebid Server includes this ID. The server pulls the base OpenRTB block from storage, then adjusts parameters like ad size or URL with any extra details from the AMP query string.
This approach means that changes to bidders or main auction settings can be made server-side and immediately go live across all related AMP inventory, greatly reducing maintenance overhead.
Implementing Stored Requests: Best Practices and Gotchas
Stored Requests can live in local files or, more commonly, in a relational database replicated across your Prebid Server installation. Proper setup is crucial for transparency and troubleshooting. Both the PBS-Go and PBS-Java variants have their own configuration approaches, but the concepts remain fundamentally similar.
Common Mistakes to Avoid
– Failing to keep stored JSON in sync across different Prebid deployments
– Hardcoding impression IDs or parameters that should remain flexible
– Not documenting updates and changes, leading to confusion during troubleshooting
Operationally, make sure your revenue and ad ops teams have clear processes for who manages stored configuration and how changes are tested before rollout.
What this means for publishers
Stored Requests centralize your auction setup, making it easier to scale header bidding across platforms and formats. Publishers gain faster turnaround for demand partner changes, improved control over auction logic, and reduced need for risky client-side deployments. This translates to quicker optimizations, fewer hardcoded mistakes, and better troubleshooting visibility for ad ops teams.
Practical takeaway
If you’re managing header bidding across mobile apps or AMP, implementing Stored Requests in Prebid Server should be on your short list for operational efficiency. Begin by mapping out which parameters (bidders, targeting, ad units) you want to control centrally, set up a stable storage backend, and define internal workflows for managing updates.
Ensure strong validation and testing practices, as a malformed stored request can disrupt many auctions at once. Finally, keep your ad ops and engineering teams aligned on configuration responsibilities and versioning. This approach minimizes deployment friction, reduces errors, and puts publishers in the driver’s seat for programmatic revenue optimization.
