Avayo Developers Analytics API API v2

Analytics API

Haal je verkoopcijfers uit Avayo en splits ze uit naar campagne, kanaal, product en tijd. Bedoeld voor rapportage en analyse, bijvoorbeeld in je eigen dashboard of in een AI-assistent.

Vijf endpoints. Authenticatie, foutmeldingen en de envelop staan op Conventies.

Verkoopcijfers

GET /api/v2/analytics/sales
ParameterStandaardWat het doet
from
to
verplichtDe periode. Maximaal 731 dagen.
date_basisorder_dateOp welke datum je rekent. Zie hieronder.
group_bygeenWaarop je uitsplitst. Komma's ertussen, maximaal drie.
metricsorders,tickets,revenueWat je wilt meten.
filter[…]geenBijvoorbeeld filter[event_id]=123.
compare_togeenprevious_period of previous_year.

Laat je group_by weg, dan krijg je één totaalrij, ook als er niets verkocht is. Nul is een antwoord.

Waarop je kunt uitsplitsen

Tijd

dateweekmonth weekdayhour

Herkomst

sourceutm_sourceutm_medium utm_campaignutm_contentutm_term promo_link

Bestelling

eventpayment_method localepostcode_area

Publiek

genderage_groupcitypostcode_keycustomer_country geo_countrygeo_regiondevice_type

Orderregel

productcategoryperformance

source is het verkoopkanaal: ticketshop, pos (kassa), backoffice, qr of guest_list. Bij verwijzingen als event en product krijg je naast het nummer ook de naam.

Maten

ordersBestellingen
ticketsTickets in die bestellingen
revenueOmzet, in euro's
discountVerleende korting
handling_costServicekosten, alleen per bestelling
avg_order_valueGemiddelde orderwaarde

Op welke datum je rekent

order_dateDe dag waarop de bestelling is aangemaakt. Standaard.
visit_dateDe dag van het bezoek. Bestellingen zonder bezoekdatum vallen hierbuiten.
completed_atHet moment van afronden. Kies deze als je cijfers gelijk moeten lopen met de omzetrapportage in je backoffice.

Uitsplitsen naar hour kan alleen met completed_at, want dat is de enige datum met een tijdstip.

Waarom twee totalen kunnen verschillen

Splits je uit op iets dat bij de hele bestelling hoort, zoals een campagne, dan is revenue de volledige orderwaarde inclusief servicekosten. Splits je uit op iets dat bij een losse regel hoort, zoals een product, dan is het de regelomzet zónder servicekosten: die horen bij de bestelling als geheel en zijn niet aan één ticketsoort toe te wijzen.

Omzet per campagne en omzet per product tellen dus niet op tot precies hetzelfde bedrag. Het veld meta.grain vertelt welke van de twee je hebt gekregen.

Standaard buiten beschouwing: testbestellingen, onbetaalde en geannuleerde bestellingen, en afrekeningen met een cashless-kaart. Die laatste omzet is al geteld bij het opwaarderen.

Verkoopverloop tegen de eventdatum

GET /api/v2/analytics/sales_curve

Twee edities naast elkaar op een kalender zeggen niets: ze vielen op andere datums. Deze curve telt terug naar de eventdatum, zodat dag 25 van deze editie naast dag 25 van vorig jaar komt te staan.

Verzoek
GET /api/v2/analytics/sales_curve
  ?event_id=123
  &compare_to_event_id=98
  &window_days=90
Eén rij uit het antwoord
{ "days_before": 25, "date": "2026-09-10",
  "orders": 84, "tickets": 197, "revenue": 4312.50,
  "compare": { "date": "2025-09-11", "orders": 61, "revenue": 3105.00 } }

Dagen die nog moeten komen zijn null

Voor een evenement dat nog niet geweest is, krijgen toekomstige dagen null en geen 0. Nul zou je grafiek naar beneden trekken alsof er niets verkocht is, terwijl die dag simpelweg nog niet geweest is. meta.today_days_before vertelt waar vandaag op de as valt. De vergelijkingscurve loopt wel door, want die editie is voorbij.

cumulative staat standaard aan en geeft absolute aantallen, geen percentage van de eindstand: voor een lopende editie is die eindstand nog niet bekend. Zet hem op false voor losse dagen.

Verkocht tegenover gescand

GET /api/v2/analytics/attendance

Hoeveel er verkocht is en hoeveel daarvan daadwerkelijk door de poort ging. Uitsplitsen kan naar source, performance en product.

Antwoord
{ "source": "backoffice", "sold": 120, "scanned": 71,
  "no_show": 49, "no_show_rate": 0.4083 }

no_show_rate is een fractie tussen 0 en 1. Geteld worden tickets, geen orderregels: een ticket is wat er door de poort gaat, en geannuleerde tickets tellen niet mee.

Gescand betekent minstens één keer

Voor een passe-partout of een abonnement dat meerdere dagen geldig is, betekent scanned dat iemand op minstens één dag is geweest, niet op elke dag. Voor de vraag of iemand is komen opdagen klopt dat; voor bezetting per dag is het iets anders.

Hoe vol zit het nog

GET /api/v2/analytics/availability

Capaciteit, verkocht, vrij en bezettingsgraad per voorstelling. Bedoeld om op te sturen: waar zet je vandaag budget op, en waar kun je stoppen met adverteren. Standaard alleen voorstellingen die nog moeten komen; met include_past=true ook de rest.

Eén voorstelling uit het antwoord
{ "performance_id": 9001, "start": "2026-10-05T20:00:00+02:00",
  "supply": "seatplan", "capacity": 312, "free": 91, "sold": 221,
  "occupancy_rate": 0.7083 }

Niet elke voorstelling heeft een capaciteit

Verkoop je zonder limiet, dan bestaat er geen bezettingsgraad. Zulke voorstellingen krijgen null in plaats van een verzonnen getal, en tellen niet mee in het totaal. Het veld supply vertelt om welk soort het gaat: seatplan, stock of unlimited.

configured_capacity is het aantal dat in de instellingen staat. Dat kan afwijken van wat er werkelijk aan stoelen of voorraad is, dus we rekenen er niet mee; capacity en free komen altijd uit dezelfde bron.

Wat er mogelijk is

GET /api/v2/analytics/dimensions

Geeft alle datumbases, dimensies, maten, filters en grenzen terug, plus de waarden die in jouw account voorkomen voor verkoopkanaal, taal en betaalmethode. Dit endpoint wordt gegenereerd uit dezelfde bron waar de query zijn werk mee doet, dus het kan niet uit de pas lopen met wat er echt kan.

Begin hier als je een koppeling bouwt. Dan hoef je geen veldnamen te raden.