What Targeter needs from you
Share the following with Targeter integration support before go-live. Targeter stores these as the connection for your platform.
Tokens are for server-to-server calls only. Issue a dedicated credential for Targeter; do not reuse a personal or dashboard login.
Conventions
- JSON request and response bodies,
Content-Type: application/json
- snake_case field names (
office_id, target_url, publisher_platforms)
- Insight windows as
YYYY-MM-DD (inclusive)
- Timestamps as UTC ISO 8601 date-times (
2026-08-20T00:00:00Z), including start_date and end_date
- IDs as opaque strings generated by you (
office_id, ad_id)
- Ids Targeter sends as opaque strings you store and return unchanged (
campaign_id)
Office mapping
Ads are attributed to an office (brokerage or advertiser account) in your system.
- Targeter looks up the office with
GET /offices using the name from the Targeter account.
- If nothing matches, Targeter calls
POST /offices. You generate office_id.
- Targeter sends that
office_id on every POST /ads.
Treat name as unique. If Targeter creates an office that already exists, return 200 with the existing office_id instead of a duplicate.
Ad lifecycle
Targeter drives delivery with these status transitions:
- Pause and resume must not delete the ad or drop historical insights.
- Delete is permanent. Targeter uses it when the campaign should not remain in your system.
- Get ad status is how Targeter syncs
scheduled, active, paused, completed, rejected, and error.
Creatives
material.target_url is always required. Provide at least one of images, videos, or html5 as publicly reachable URLs. Targeter will only request formats listed for each platform in GET /publisher-platforms.
Going live
- Stand up the endpoints against a sandbox host.
- Send Targeter the sandbox base URL and token.
- Targeter runs the typical flow: platforms → office → create ad → status → insights → pause/resume.
- Switch the stored base URL and token to production.
