Demand partners

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

BidSwitch sub-DSPs

Reached through BidSwitch: supply the raw DSP seat ID in seatIds.

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:

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), several joined
by commas. On PATCH they arrive as one { "message": "…" } with no field
paths, their parts joined by semicolons:

{
  "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. In addition, adFormat and environments cannot be changed on an
existing deal with a dv360 buyer: DV360 fixes the format and medium type when
the deal is created. Create a new deal request instead.

The medium type DV360 lists a deal under follows from its adFormat and
environments. A deal with more than one environment is listed under DV360's
Digital medium type, which includes CTV. A banner, video or native deal
whose only environment is ctv is listed under TV.

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).

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:

{
  "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.