SDK Data Handling Notice
The data accepted and returned by Posto's advertising SDK interfaces and the integration duties that accompany their use. This Notice forms part of the integration requirements under the Terms of Service and Developer Terms.
Effective 2026-10-02 · Version 2026-10-02 · Permanent version
1. Permitted request data
A production ad request includes a placement identifier, format, and recent interaction context permitted by the applicable integration documentation. Developer shall comply with the supported content schema and size limits and shall submit no more information than necessary for the requested advertising function. Detailed implementation requirements are supplied through the applicable developer documentation.
Developer may optionally submit an age range of 18–24, 25–34, 35–44, 45–54, or 55+; a gender value of women, men, or non-binary; and coarse country, region, or city, where obtained from a lawful first-party source. The interface does not accept GPS coordinates, postal codes, street addresses, interests, arbitrary user attributes, user identifiers, images, or commerce dictionaries as contextual fields. The listed schema is a limit on submissions, not authorization to infer or collect a prohibited sensitive characteristic.
2. Filtering, residual information, and retention
The integration includes input-filtering controls. Developer shall use the supplied filtering and shall not disable or evade it. Such controls can miss identifiers, sensitive subject matter, or combinations that reveal an individual. Filtered or redacted information shall therefore not be presumed anonymous, and filtering is not permission to send prohibited information.
Ad-request text and related original or derived text retained as delivery or diagnostic copies are removed under the applicable 30-day retention schedule and may be deleted earlier. Structured categories and numeric measures, hashes, event identities, risk outcomes, and permitted aggregates may remain for their separate operational or legal periods. Non-billable SDK test records and tokens are retained for 7 days. These periods do not authorize retaining an undisclosed copy of a conversation or treating pseudonymous residual records as anonymous.
3. Advertising selection and automated processing
Posto uses permitted request information and applicable campaign or audience constraints to select eligible advertisements and support the enabled Service functions. Optional demographic information shall be limited to the permitted audience purpose and shall not be used to create an unrelated profile.
Third-party AI service providers may process submitted information necessary for enabled advertising or assistance functions, as described in the Privacy Policy and provider disclosure. Input filtering does not guarantee that this information contains no personal information. Customer shall not submit sensitive conversations or rely on an assumption that every unsafe context will be suppressed.
4. Authentication and integrity
Web and backend integrations use per-application server HMAC authentication. Supported iOS direct requests use Apple App Attest and supported Android direct requests use Google Play Integrity. Applicable proofs and signed request controls bind app or installation information, request hashes, timestamps, and idempotency values to limit spoofing and replay.
The ad-request interface does not require a Customer-supplied advertising identifier or hardware serial number. Verification still involves technical and potentially personal information, including integrity proofs and request metadata. Non-attested test endpoints are non-billable and return test-only advertisements. Developer shall protect server credentials and use each authentication path only as documented.
5. Response fields and token confidentiality
A filled response contains a request identifier and one advertisement with its identifier, format, advertiser, headline, body, call to action, optional image URL, required image alternative text, and private impression and click tokens. A no-fill response contains the request identifier and a null advertisement.
The initial response does not expose the landing URL, auction identifier, match scores, internal product information, or raw tracking endpoints. The SDK shall retain tracking tokens privately for their intended event flow. Developer shall not extract or repurpose them to bypass verification or identify End Users.
6. Impressions, clicks, and disclosure
Developer shall invoke the SDK's impression method only after rendering the advertisement as required by the documentation. On an intentional human click, the SDK submits the signed click event; after validation, Posto returns a short-lived redirect URL that the SDK opens. Duplicate or replayed submissions are handled through the applicable idempotency controls and shall not be used to generate additional billable activity.
Developer shall display the prescribed advertising label clearly and conspicuously and comply with the affiliate-disclosure requirements where applicable. An impression, click, or contractual acceptance is not a substitute for any separate privacy consent required for the underlying processing.
7. Developer privacy responsibilities and requests
Developer shall maintain an accurate, easily accessible notice identifying Posto, linking to Posto's legal notices, and explaining the categories, purposes, recipients, retention, and choices applicable to its actual integration. Developer shall obtain a lawful basis and required specific consent, honor applicable platform requirements and legally binding privacy signals, avoid prohibited children's or sensitive information, minimize inputs, and provide a secure means of exercising rights.
Processor-assistance requests may be sent to legal@postoconnect.com. End Users may contact Developer or Posto directly; contacting Developer first is not a condition of exercising a statutory right. Developer's obligations supplement Posto's own obligations under the Agreement and applicable law rather than replacing them.