Return LinkedIn bidding configuration on ad read endpoints
Hi,
We'd like to request that the effective LinkedIn bidding configuration is returned on the ad read endpoints.
When creating a LinkedIn boost campaign, platformSpecificData accepts fields such as:
costTypeunitCostoptimizationTargetType
However, none of these values are returned by any read endpoint afterwards. While bidAmount exists, it is documented as Meta/TikTok only, leaving no way to verify the bidding configuration that was actually created for a LinkedIn campaign.
This became a real issue for us recently. We spent two days investigating a campaign that showed as ACTIVE but never delivered any impressions. Ultimately, LinkedIn Campaign Manager revealed that the campaign had been created in manual bidding mode with a €0 bid. There was no way to detect or verify this through the API. (Support is already tracking the related manual-bidding / €0 unitCost issue.)
If the effective bidding configuration were returned, we could immediately verify after creation that the campaign matches the intended bidding mode. That would allow us to fail fast, alert customers immediately, or automatically detect unexpected configurations instead of discovering the issue only after days of zero delivery.
Request
Please include the effective LinkedIn values for:
costTypeunitCostoptimizationTargetType
on GET /v1/ads/{id} (and, if possible, on the list endpoint as well).
Being able to read back the effective bidding configuration would make campaign creation verifiable and greatly simplify troubleshooting when campaigns are technically active but not serving.
Log in to comment and vote
Comments1
Aug 1
PinnedShipped and live.
Ad reads now return costType, bidAmount (LinkedIn's unitCost, whole currency units) and optimizationGoal (optimizationTargetType), on GET /v1/ads/{adId}, GET /v1/ads, and the tree ad and ad-set nodes. These are the values LinkedIn actually applied, so you can create and then verify.
We reused the existing bidAmount and optimizationGoal fields on purpose: the create path already writes there, and a separate read shape would have broken the round trip this request is for.
The detail that matters for your case: bidAmount: 0 is preserved as a real value, never dropped as unset. A truthiness check would have discarded it, which is exactly what kept your incident invisible. So the signature to alert on is a manual costType with bidAmount: 0, or optimizationGoal: NONE.
Not yet covered: GET /v1/ads/campaigns reads a separate collection. bidAmount and optimizationGoal will appear there on their own as campaigns roll up; costType needs a backfill we have not run.
Populates per account on the next sync.