1. Request data
A production ad request contains placement ID, format, and context. Context contains 1–6 alternating user/assistant messages representing at most the most recent three complete turns and must include at least one user message. Each message is limited to 4,000 UTF-8 bytes and the transcript to 16,000 bytes.
An app may optionally send age range (18–24, 25–34, 35–44, 45–54, or 55+), gender (women, men, or non-binary), and coarse country, region, or city. These fields must reflect a lawful first-party source. GPS coordinates, postal codes, street addresses, interests, arbitrary user attributes, user IDs, images, and commerce dictionaries are not accepted.
2. PII filtering
Current SDKs perform deterministic PII filtering before transmission and Posto repeats filtering server-side. Developers must not rely on filtering as permission to submit sensitive data and must not disable it. Redacted message text is retained for up to 30 days for delivery diagnosis, then removed while derived intent, hashes, risk outcomes, and aggregates may remain.
3. Matching
User messages form the authoritative commercial query. Earlier user messages may supply category, location, budget, and constraints. Assistant messages are embedded separately and can provide only a bounded reference adjustment among candidates that already passed user-text semantic and hard gates. Optional demographics are used only for matching an explicit audience constraint and never enter embeddings.
4. Authentication and integrity
Web and backend integrations use per-app server HMAC. iOS direct requests use Apple App Attest and Android direct requests use Google Play Integrity. Proofs bind the app installation, request hash, timestamp, and idempotency key. Posto does not require a customer-provided advertising ID or hardware device ID. Non-attested test endpoints are non-billable and return test-only ads.
5. Response data
A filled response contains request ID and one ad with ID, format, advertiser, headline, body, CTA, optional image URL, required alt text for images, and private impression and click tokens. A no-fill response contains the request ID and a null ad. Landing URLs, auction IDs, match scores, internal product data, and raw tracking endpoints are not exposed in the initial response.
6. Impression and click
The SDK keeps tracking tokens private. The app calls the SDK's impression method after rendering. On an intentional click, the SDK submits a signed click event; Posto validates the request and returns a short-lived redirect URL, which the SDK opens. Replays are idempotent. The app must show the prescribed advertising disclosure.
7. Developer obligations
Publish an accurate privacy notice, obtain required consent or other legal basis, honor platform permissions, avoid sensitive contexts, and provide a way for users to exercise rights. Contact privacy@postoconnect.com for a data request that Posto must assist with as processor.