How to Integrate a DSP with Ad Exchanges and SSPs

When most people in the online advertising world talk about integrating a demand-side platform (DSP) with an ad exchange or supply-side platform (SSP), they make it sound as if it's a matter of connecting two platforms together with a cable.

In reality, integrating a DSP with other AdTech platforms is a meticulous technical process that can take anywhere from four to six weeks — roughly two to three development sprints.

Why DSPs Need to Integrate With Ad Exchanges and SSPs

Demand-side platforms play a key role in helping advertisers and ad agencies run online media campaigns. They provide features to create, run, measure, and optimize campaigns across different mediums (laptops, mobile devices) and channels such as display, video, and native.

To do any of that, though, a DSP must connect to other AdTech platforms in order to purchase available ad inventory from publishers.

The most common mechanism for DSPs to buy ad space on websites and apps is real-time bidding (RTB). RTB is a live auction process whereby DSPs bid on impressions offered by ad exchanges and supply-side platforms (SSPs).

Without integrating with at least one ad exchange or SSP, a demand-side platform has no way to purchase online advertising inventory at all.

How the DSP Integration Process Works

Different teams approach integration somewhat differently, but the process breaks down into three core phases, followed by ongoing maintenance.

Here is a practical overview of what each phase involves:

Phase 1: Research and Setup

The initial phase is largely investigative. It typically involves:

• Analyzing documentation provided by the ad exchange or SSP, consulting with their team to determine the target OpenRTB version, and identifying any custom extensions they may have added on top of the standard protocol.
• Discovering business requirements for obtaining a seat — some ad exchanges and SSPs impose a minimum monthly account spend before granting access.
• Researching quality standards — understanding which creative categories the partner accepts and what ad-quality requirements they enforce.
• Participating in quality audits — most partners require the DSP to conduct an audit on creatives or specific content categories as part of onboarding.
• Determining the communication protocol — while OpenRTB is the dominant standard, some SSPs and ad exchanges operate their own proprietary protocols alongside or instead of it.
• Evaluating the budget-control component — for lower-volume scenarios where win notifications arrive within seconds of the bid, a loose (or "naive") budget-control approach is generally sufficient. At higher volumes, or where notifications can arrive minutes after the bid, a strict ("banker") budget-control component is typically required.
• Deciding on creative delivery — creatives (ads) can either be delivered by the bidder in the bid responses or served from an external ad server.

This initial phase typically requires one sprint (two weeks) to complete.

Phase 2: Development and Implementation

The second phase is where the actual building happens. Development and implementation generally includes:

• Modifying the DSP's bidder to ensure compatibility with the ad exchange's or SSP's version of the OpenRTB protocol, including any custom arrangements such as additional fields passed in the bid request.
• Building or configuring an ad server — either constructing one or setting up an external ad server (such as Kevel) to serve creatives.
• Adjusting the request path and bid-request implementation to match the specific requirements of the target ad exchange or SSP.
• Mapping content categories — ad exchanges and SSPs frequently have additional or differently labelled content categories that need to be mapped to the DSP's own taxonomy.
• Defining billing and reporting methods to ensure campaign budgets are tracked and reported correctly and that performance data surfaces as promptly as possible.

Phase 2 generally takes two sprints (four weeks) to complete.

Phase 3: Testing the Integration

Testing the DSP and SSP integration

The final phase runs the integration against live traffic — typically starting with a small volume — and focuses on:

• Analyzing bid-request performance and speed between the platforms to ensure the DSP is not being consistently timed out.
• Reducing reporting and billing discrepancies between the DSP and the ad exchange or SSP. During initial testing, achieving a discrepancy within 10% — the target recommended by the IAB — is the primary goal. From there, tracking and reporting logic should be continuously refined to drive discrepancies lower over time.

The testing phase takes approximately one sprint (two weeks) to complete.

Phase 4: Post-Integration Maintenance

Once integration is live, ongoing maintenance becomes part of the workload. This typically includes:

• Updating the integration when the partner's API or OpenRTB version changes.
• Continuously optimizing reporting and billing trackers to reduce discrepancies between the DSP and the SSP or ad exchange.

The overview above should be broadly legible to experienced AdTech practitioners, but the underlying technical work demands a deep understanding of the online-advertising ecosystem as a whole and real hands-on development experience with programmatic systems.