A Publisher’s Guide to Prebid Server Endpoints: How They Power Header Bidding
For publishers relying on header bidding, Prebid Server is the backbone of scalable, high-performing ad auctions. But underneath the hood, Prebid Server exposes various API endpoints that control everything from bid requests to user ID syncing. Understanding these endpoints isn’t just for developers—publishers, ad ops, and monetization teams who know how these connections work are better equipped to troubleshoot issues and maximize yield.
This guide breaks down the essential Prebid Server and Prebid Cache endpoints, spotlighting what each one does, how they fit into header bidding flows, and what practical impact they have on your ad stack. Whether you manage Prebid.js directly or work with a managed service, knowing how Prebid Server orchestrates auctions and identity will sharpen your operational toolkit.
Core Prebid Server Endpoints and Their Roles
Prebid Server provides a set of API endpoints, each designed for a specific function in the header bidding workflow. Knowing when and why each endpoint gets called is crucial for effective troubleshooting and optimization.
/openrtb2/auction: The Main Auction Endpoint
This POST endpoint handles the primary header bidding auction. When a user loads a page, Prebid.js or your integration triggers this endpoint to gather bids from demand partners using the OpenRTB protocol. It’s the nerve center for all browser and server-side header bidding activity.
/openrtb2/amp: AMP Page Bidding
AMP pages can’t use traditional JavaScript bidders, so Prebid Server provides a dedicated GET endpoint to support auctions on AMP-enabled content. If you monetize with AMP pages, this is essential for tapping into header bidding demand.
/openrtb2/video: Video Ad Requests
Video inventory—especially long-form video—has distinct requirements. This POST endpoint ensures that video ad calls leverage demand partners that support the v2 OpenRTB Video spec. Useful for CTV, OTT, and premium video publishers.
User ID Sync and Cookie Management Endpoints
Identity is a cornerstone of header bidding. Prebid Server encapsulates user identity sync through specific endpoints, making cross-device targeting and partner cookie mapping possible.
/cookie_sync: Kicking Off Identity Matching
The /cookie_sync endpoint provides a list of third-party pixel syncs your client-side code can execute. It’s the starting point for aligning user IDs between your domain and various SSPs or DSPs.
/setuid and /getuids: Updating and Reading User IDs
/setuid actually updates the user ID cookies based on sync activity, while /getuids reads and returns the mapped IDs in JSON. Understanding these flows helps diagnose issues where demand partners are seeing blank or mismatched IDs.
Supporting and Administrative Endpoints
Beyond auctions and identity, Prebid Server includes endpoints for health monitoring, caching, and configuration visibility. These endpoints matter for reliability and maintaining a healthy ad stack.
/status: Server Health Checks
Monitors the operational status of your Prebid Server instance. Essential for uptime monitoring and rapid troubleshooting during outages.
/info: Configuration Transparency
Returns runtime details about how your Prebid Server is configured—such as enabled adapters and timeout settings. Use this when reviewing changes or debugging integration issues.
/event and /vtrack: Event Processing and VAST Caching
/event notifies Prebid Server about user actions like impressions or clicks. /vtrack is used for storing VAST XML with embedded tracking, relevant for video ad tracking and analytics workflows.
Prebid Cache Endpoints in Ad Delivery
Efficient creative serving and reporting depend on Prebid Cache endpoints, especially for server-side integrations and video ads. These endpoints are essential for linking auction results to delivery.
/cache: Storing and Retrieving Bids
POST /cache allows Prebid Server to store bids or VAST XML, returning a cache ID that links the winning bid to ad delivery. GET /cache retrieves these creatives or VAST XML when it’s time to render the ad. Publishers who see ‘no ad found’ errors in video often have configuration mismatches here.
What this means for publishers
Understanding Prebid Server endpoints unlocks better control over your monetization stack. It helps you pinpoint where auctions may be failing, why user identity syncs aren’t working, or where creatives go missing in the delivery chain. With this knowledge, you’re less reliant on black-box troubleshooting and more empowered to actively manage partners, spot revenue-impacting issues, and ensure a consistently high fill rate across different formats and devices.
Practical takeaway
Practical familiarity with Prebid Server and Prebid Cache endpoints equips publisher teams to solve real-world problems faster—whether it’s laggy auctions, missing creatives, or broken AMP monetization. Regularly audit how your stack invokes these endpoints and monitor logs for errors, especially around user ID syncing or ad caching.
Start by mapping each endpoint to your current header bidding workflow and make sure your analytics (or reporting from your Prebid-as-a-Service vendor) covers error rates and response times for each. For advanced teams, implement automated monitoring to alert on /status endpoint issues and cache mismatches. As header bidding complexity grows, a solid grasp of these fundamentals will keep your operations scalable and resilient.
