> For the complete documentation index, see [llms.txt](https://docs.exoclick.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.exoclick.com/api/ad-placement-api/ad-plac-request.md). # Request The Ad Placement API can be called from either **client** side or **server** side. When using **client** side implementation, the browser may perform a **pre-flight** request. If you wish to avoid this, in the request header, use `Content-Type: text/plain`. This will ensure that the browser qualifies the request as "simple" and therefore skips the pre-flight request. Also, when calling the API on the **client** side, **IPs are not actually required** as it can be difficult to detect IP using frontend and Javascript. Instead, our API detects the IP from the connection when the request is made. When using **server** side implementation, in order to ensure correct targeting, **the correct IP of the user should be passed explicitly**. Otherwise, ads will be targeted for server location and this may cause impressions to be invalidated by an IP mismatch later. Whether client or server is used, if an IP is passed, it will be prioritised over the one we detect. In order to perform a request to the ad placement API, you need to pass two objects: **user** and **zones**. The request is made in JSON using HTTP POST. ## user | Parameter | Required? | Description | | ------------------- | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | id | No | The ID of the user | | ip | Recommended | The user IP address. | | ua | Yes | The User Agent: A string containing the user's browser/app and device/OS. | | language | No | Sets the language of the request using the [standard two-character ISO code](https://www.andiamo.co.uk/resources/iso-language-codes/) plus an optional 2-character region code. e.g. `en-us` for United States English. | | referer | No | The address of the site where the ad will be shown. | | el | No | The Base64-encoded email of the user. | | screen\_resolution | No | Screen resolution of the device used by user | | window\_orientation | No | This should be "portrait" if the site has a mobile layout and "landscape" if it's a desktop one. | | gdpr | No | Privacy advised extensions (Object). | ### user.gdpr | Parameter | Description | | --------- | ----------------------------------------------------------------------------------------------------------------- | | gdpr | This should be **0** if the caller believes that the user is not under GDPR, and **1** if the user is under GDPR. | | consent | This is the consent string required by the IAB Standards. | ## zones | Parameter | Required? | Description | | ----------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | id | Yes | The ID of the ad zone | | sub | No | The Sub ID of the ad zone | | keywords | No | Any [keywords](/advertisers/campaigns/creating-a-campaign/create-campaign-step3.md#keywords) associated to the traffic that might match with a specific type of advertising. If there are no keywords, the URL of the site will be used for matching | | custom\_targeting | No | Custom zone values (Object) | ### zones.custom\_targeting | Parameter | Description | | --------- | -------------------------------------------------------------------------------------- | | ex\_av | This should be **0** if Undefined, **1** if Age Verified and **2** if Age Not Verified | ## Example It is possible to request many ad zones in a single request. Each zone will have a different ID, as you can see in the example below. ```json { "user": { "id": "abdef8u9", "ip": "10.42.0.1", "ua": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.63 Safari/537.36", "language": "en-US", "referer": "https://blabla.com", "gdpr": { "gdpr": 1, "consent": "CPAoZRHPArq3hBcADBENBJCgAAAAAAAAAAqIHKQAAOUgAAAA" } }, "zones": [ { "id": 4031007, "sub": 111, "keywords": "humour, general" }, { "id": 4031015, "sub": 222 }, { "id": 4031019, "sub": 222 } ] } ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.exoclick.com/api/ad-placement-api/ad-plac-request.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.