Partner-API

Zugang

Die API ist für Partner mit API-Zugang. Die Zugangsdaten vergibt die Administration. Es gibt keine Selbstregistrierung und keinen Key-Generator im Dashboard.

Basis-URL

https://adyoutiser.com/api/v1

Auth-Header

Authorization: Bearer <token>Einen Header X-API-Key gibt es nicht.

Fehlerformat

application/problem+json (RFC 7807)

Rate-Limit

600 Anfragen pro Minute pro Zugang, voreingestellt.

Authentifizierung

Schick den Token im Authorization-Header. Das Präfix entscheidet, wie er gelesen wird: ein Wert, der mit adyo_ beginnt, gilt als API-Key, alles andere als OAuth-Zugriffstoken.

curl -H "Authorization: Bearer adyo_your_api_key" \
  "https://adyoutiser.com/api/v1/screens?city=Wien&limit=50"

curl -X POST "https://adyoutiser.com/api/v1/oauth/token" \
  -H "Content-Type: application/json" \
  -d '{"client_id":"YOUR_CLIENT_ID","client_secret":"YOUR_CLIENT_SECRET"}'

{
  "access_token": "...",
  "token_type": "bearer",
  "expires_in": 3600,
  "scope": "screens:read"
}

Limits und Fehler

HTTP/1.1 429 Too Many Requests
Content-Type: application/problem+json
Retry-After: 60

Jeder Fehler-Body folgt RFC 7807 mit dem Content-Type application/problem+json.

type

Kennung des Fehlertyps.

title

Kurze Bezeichnung des Fehlers.

status

Der HTTP-Statuscode.

detail

Was bei diesem konkreten Aufruf schiefging.

retry_after

Nur bei 429. Wartezeit in Sekunden.

Endpunkte

Screens. GET /screens liefert { data, pagination } mit cursor, has_more und total_count. Filter: country (2 Buchstaben), city, orientation, bbox. limit ist voreingestellt auf 50, Maximum 200; geblättert wird über cursor.

{
  "id": "...",
  "name": "...",
  "description": "...",
  "country": "AT",
  "city": "Wien",
  "address": "...",
  "latitude": 0,
  "longitude": 0,
  "orientation": "portrait",
  "resolution_width": 1080,
  "resolution_height": 1920,
  "price_per_day_cents": 0,
  "ad_sov_pct": 0,
  "thumbnail_url": "...",
  "venue_type": "...",
  "is_active": true,
  "created_at": "..."
}

Verfügbarkeit. from und to sind Pflicht, Format YYYY-MM-DD. Die Antwort enthält screen_id, from, to, max_sov_pct, used_sov_pct, available_sov_pct und price_per_day_cents.

curl -H "Authorization: Bearer adyo_your_api_key" \
  "https://adyoutiser.com/api/v1/screens/SCREEN_ID/availability?from=2026-09-01&to=2026-09-07"

Gutscheine. POST /coupons antwortet mit 201. Pflicht: discount_type (percent, amount_cents oder free_days), discount_value größer 0, und lead_email. Optional: code, max_redemptions (1–1000, Voreinstellung 1), valid_until, lead_metadata. Ohne eigenen code wird einer im Muster BVCC-XXXX erzeugt.

curl -X POST "https://adyoutiser.com/api/v1/coupons" \
  -H "Authorization: Bearer adyo_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "discount_type": "percent",
    "discount_value": 10,
    "lead_email": "lead@example.com",
    "max_redemptions": 1
  }'

Nutzer. GET /users/lookup nimmt email oder vat_uid. Du bekommst entweder { "data": { "exists": false } } oder einen Datensatz mit user_id, registered_at, has_bookings und optional attribution. Die Attributionsdaten kommen nur zurück, wenn die Vermittlung deinem eigenen Zugang zuzuordnen ist.

Landing-Links. POST /landing-links antwortet mit 201 und liefert eine url samt UTM-Parametern. utm_medium ist immer partner_api.

Kampagnenanfragen. GET /campaign-requests filtert nach status (rejected, abandoned, no_inventory, converted), from, to und industry. Du siehst immer nur deine eigenen Anfragen.

Webhooks

X-Adyoutiser-Signature: t=1754438400,v1=<hex>