--- updatedAt: 2026-10-05T21:37:06.000Z agentTools: projectIndex: https://developer.sovrn.com/llms.txt --- # Demand partners The partner slugs accepted in a buyer's partner field, the DV360 field rules, and which deals let you set their status. Set each buyer's `partner` to one of the slugs below. **Direct** DSPs use their own slug. **BidSwitch** sub-DSPs use a `bsw-`-prefixed slug; for those, put the raw DSP seat ID in `seatIds` (do not include a `:`). If you work with a partner that isn't listed, ask your Sovrn representative. ## Direct partners | Slug | Partner | | -------------- | ----------------------- | | `simpli.fi` | Simpli.fi | | `basis` | Basis (Centro) | | `dv360` | DV360 (DBM) | | `thetradedesk` | TradeDesk | | `quantcast` | Quantcast | | `pulsepoint` | PulsePoint | | `pubmatic` | Pubmatic | | `illumin` | Illumin (AcuityAds) | | `pubmatic-uk` | Pubmatic UK | | `openx` | OpenX | | `magnite` | Magnite (Rubicon) | | `magnite-uk` | Magnite UK (Rubicon UK) | | `clickagy` | Clickagy | | `beeswax` | Beeswax | | `rtbhouse` | RTB House | | `mediaforce` | Media Force | | `xandr` | Xandr | | `nexxen` | Nexxen (Unruly) | | `epom` | Epom | | `madhive` | Madhive | | `krush` | Krush Media | | `opera` | Opera | | `motorik` | Motorik | | `equativ` | Equativ | | `emodo` | Emodo | | `smaato` | Smaato | | `edge226` | Edge226 | | `decenterads` | DecenterAds | | `consumable` | Consumable | | `epsilon` | Epsilon | | `boldwin` | Boldwin | | `taurusx` | TaurusX | | `stirista` | Stirista | | `140proof` | 140Proof | | `altavara` | Altavara | | `adipolo` | Adipolo | | `madopi` | Madopi | ## BidSwitch sub-DSPs Reached through BidSwitch: supply the raw DSP seat ID in `seatIds`. | Slug | DSP | | --------------------- | -------------------- | | `bsw-ninedotsmedia` | 9 dots media | | `bsw-adelement` | AdElement | | `bsw-adform` | Adform | | `bsw-adingenious` | AdIngenious | | `bsw-admatic` | Admatic DSP | | `bsw-admixer` | Admixer | | `bsw-amazon` | Amazon DSP | | `bsw-appier` | Appier | | `bsw-aroscop` | Aroscop | | `bsw-azberry` | Azberry | | `bsw-bedrockplatform` | Bedrock Platform | | `bsw-betweenexchange` | Between Exchange | | `bsw-boldwin` | Bold-win | | `bsw-criteo` | Criteo | | `bsw-edge226` | Edge226 | | `bsw-igaworks` | IGAWorks | | `bsw-instal` | Instal | | `bsw-iponwebbidcore` | IPONWEB BidCore | | `bsw-knorex` | Knorex | | `bsw-lift` | Lift | | `bsw-madopi` | Madopi | | `bsw-madopimedia` | Madopi Media | | `bsw-marketperf` | Marketperf | | `bsw-my6sense` | my6sense | | `bsw-nrich` | N.RICH | | `bsw-nextroll` | NextRoll | | `bsw-samsung` | Samsung DSP (AdGear) | | `bsw-sportradar` | Sportradar | | `bsw-taptap` | TAPTAP | | `bsw-webeye` | Webeye | | `bsw-yahoo` | Yahoo DSP | | `bsw-zetaglobal` | Zeta Global DSP | ## DV360 requirements A deal whose buyers include `dv360` is also created on DV360's side (an Auction Package for `open` deals, a Deal Sync product for `pmp`), and DV360 requires fields this API otherwise treats as optional. A request with a `dv360` buyer must meet all of the following, or it returns `400`: | Field | Requirement | | -------------------- | ------------------------------------------------------------------ | | `description` | Required. At most 2000 characters for `open` deals, 250 for `pmp`. | | `schedule.endDate` | Required, and later than `schedule.startDate`. | | `schedule.startDate` | Within 365 days of today (UTC). | | `pricing.floor` | Required, with at most 6 decimal places. | | `name` | At most 240 characters. | `pricing.floor` must also be greater than 0, but that rule applies to every deal, and its message does not name DV360: `body/pricing/floor Too small: expected number to be >0`. The messages for these rules name the field and DV360, and how they arrive depends on the request. On `POST` each one carries its field path in the validation shape (see [Errors](https://developer.sovrn.com/docs/errors#validation-errors)), several joined by commas. On `PATCH` they arrive as one `{ "message": "…" }` with no field paths, their parts joined by semicolons: ```json { "message": "description is required for DV360 buyers (max 250 characters for pmp deals); schedule.endDate is required for DV360 buyers" } ``` The same rules apply to the merged result of a `PATCH`, so a deal with a `dv360` buyer that is missing a field now required must supply it in the same `PATCH`. Until it does, every `PATCH` to that deal is refused, a status change included. DV360 also fixes a deal's format and its medium type when the deal is created, and DOOH isn't available on DV360 deals. On an existing deal with a `dv360` buyer: * `adFormat` cannot be changed. * `environments` cannot include `dooh`. * `environments` can change only to a list that keeps the deal's medium type. To change the format or the medium type, create a new deal request instead. The medium type DV360 lists a deal under follows from its `adFormat` and `environments`: | Medium type | Deals | | ----------- | ------------------------------------------------------------------------------------------------------------------- | | TV | A `banner`, `video` or `native` deal whose only environment is `ctv`. | | Audio | An `audio` deal whose only environment is `web`, or whose only environment is `app`. | | Digital | Every other deal on `web`, `app` or `ctv`, including any deal with more than one environment. Digital includes CTV. | So a `banner`, `video` or `native` deal on `web` can add `app`, and one on `web` and `app` can drop either: it stays Digital. Such a deal cannot go from `ctv` alone to `ctv` and `web`, or from `web` and `ctv` to `ctv` alone: that moves it between TV and Digital. An `audio` deal on `web` cannot add `app`: that moves it from Audio to Digital. A `PATCH` that breaks one of these rules returns `400` with a message naming it. One that would change the medium type names the change: ```json { "message": "environments can't change from ctv to ctv, web on a deal with a DV360 buyer, because that would change the deal's DV360 medium type; create a new deal request instead" } ``` One whose `environments` include `dooh` returns `environments can't include dooh on a deal with a DV360 buyer, because DOOH isn't available on DV360 deals`. ## Deals you can pause yourself Most DSPs leave a deal's status to you: `PATCH /deal-requests/{id}` with a `status` pauses, resumes, schedules or archives the deal (see [Deal lifecycle](https://developer.sovrn.com/docs/deal-lifecycle#changing-a-deals-status)). `dv360` is the exception. DV360 manages the status of its own deals through its integration, and this API does not change it. A deal whose buyers are **all** `dv360` therefore rejects `status`: ```json { "message": "status is not settable on this deal: every buyer is on a DSP that manages deal status through its own integration (dv360)" } ``` A deal that mixes `dv360` with other buyers accepts the change: the other buyers are set, the `dv360` buyer is left as it is, and the deal's own status is worked out from all of its buyers together. So only `paused` on a `pmp` deal always resolves as sent. Any other value resolves as sent only if the `dv360` buyer is already in that state on DV360's side, and otherwise the deal reads back `review`; a deal you tried to archive that way stays in list results. You do not have to track which DSPs are which. `GET /deal-requests/{id}` and the `200` from a `PATCH` carry a `statusSettable` boolean that answers it for that deal (list items and the `201` from a create do not), and it is `false` for the mixed case above too, because the status such a deal resolves to is not always the one you sent. See [Deal lifecycle](https://developer.sovrn.com/docs/deal-lifecycle#ask-the-deal-not-the-dsp).