Enrich many OpenRTB bid requests in one call
An array of OpenRTB 2.6 bid requests in; an array of passthrough responses out,
same order, one-to-one. An invalid item occupies its slot with the {code, message} error object its single-request 400 would have carried — the one
sanctioned non-OpenRTB element in this route’s 2xx responses — while valid items
resolve normally. Exceeding the documented item cap fails the whole batch with
400. Each item counts as one unit against your rate limit and your usage. No
query parameters; no latency SLA on batch. Per-item diagnostic signaling on this route
is provisional — a batch caller that needs a per-item outcome, confidence, or
reason should use the parameterized lookup batch, whose envelope carries them.
Authentication
Your Pixalate-provided API key, in the request header on every route. Credentials are never accepted in query parameters. An API key may be obtained by signing up for an account on the Pixalate developer website.
Username/password alternative to the API-key header. Headers only — credentials are never accepted in query parameters.
Request
Response
Batch processed; inspect each slot for the per-item outcome — an enriched or unchanged bid request, or an error object for an invalid item.
A standard OpenRTB 2.6 bid request. The service reads only the input subset below,
from their canonical OpenRTB paths, and validates those read fields strictly (a
required read field missing or empty, or any read field of the wrong type → 400; a
malformed optional read field is treated as absent); all other fields are permitted,
ignored, and preserved in the response. OpenRTB’s own required fields (id, imp)
are not enforced — a lookup-only body may omit them.