Hent MRR inklusive rabatter via API'et
Kunde-API'et viser nu både aktuel og afventende MRR inklusive tidsbegrænsede rabatter. De nye felter effectivemrrbycurrency og effectivependingmrrbycurrency svarer til kolonnerne "MRR inkl. rabatter" og "Afventende MRR inkl. rabatter" i CSV-eksporten.
Kunde-API’et viser nu både aktuel og afventende MRR inklusive tidsbegrænsede rabatter. De nye felter effective_mrr_by_currency og effective_pending_mrr_by_currency svarer til kolonnerne “MRR inkl. rabatter” og “Afventende MRR inkl. rabatter” i CSV-eksporten.
Aktiv MRR og afventende MRR er fortsat adskilt: Afventende MRR omfatter abonnementer med fremtidig startdato, aktiv prøveperiode eller pause. Alle fire API-felter er opdelt pr. valuta og angivet i den mindste valutaenhed, fx øre.
Historisk baggrund - august 2024 til september 2026
MRR-API’et blev først brugt til at hente aktuelle nøgletal og blev senere udvidet med afventende tal, rabatter, intervaller og planlagte ændringer. Et API-svar om en konkret subscription er altid vigtigere end planens katalogpris, fordi abonnementet kan have sin egen pris, valuta, prøveperiode eller rabat.
Når en integrator ændrer trial, rabat eller fornyelsesinterval, skal den læse det opdaterede abonnement tilbage og skelne mellem en ændring, der gælder nu, og en planlagt ændring. Brug UUID’er, pagination og beløbsenheden fra OpenAPI-specifikationen. Se vejledningen til offentlig API og webhooks (Markdown-fil, AI-agentvenlig).
En ændring fra læsning til læsning igen
Start med GET /api/v1/subscriptions/{uuid} med den fiktive, ikke-eksisterende UUID 00000000-0000-4000-8000-000000000003 i et testeksempel. Gem den aktuelle pris, pricing type, interval, trial og available_price_change_dates, før du sender en ændring. Send derefter kun den handling, du vil udføre, og læs subscription-responsen tilbage. API’et returnerer den opdaterede subscription og kan angive den faktiske ikrafttrædelsesdato i meta.effective_date.
Prøveperiode
Brug PUT /api/v1/subscriptions/{uuid}/trial med { "end_date": "2026-10-15" } for en eksisterende, ulåst trial. Endedatoen skal ligge efter trialens startdato. En subscription uden trial eller en trial, hvis transaktion allerede er faktureret eller trukket, giver 422; API’et opretter ikke en trial ved dette kald.
Rabat
Brug POST /api/v1/subscriptions/{uuid}/discounts med en dokumenteret rabattype. En procent-rabat som 14.29 betyder 14,29 procent, mens en fixed-rabat er i mindste valutaenhed, fx 5000 = 50,00. Rabatvinduet skal starte ved en ulåst periode og må ikke overlappe en anden ventende rabat. Usage-baserede abonnementer understøtter procent-rabat, mens en fixed-rabat afvises.
Interval og pris
PUT /api/v1/subscriptions/{uuid}/interval med fx { "interval": 3 } bruger de intervaller, planen har konfigureret, og gælder fra den næste kommende periode. PUT /api/v1/subscriptions/{uuid}/price tager price for flat-rate eller unit_price for license-based; de to felter må ikke blandes. Prisændringer gælder som udgangspunkt næste periode, eller en gyldig effective_date, og usage-baserede/tiered priser ændres gennem deres egne prisregler.
En planlagt ændring er ikke allerede aktiv. Hvis en periode er faktureret eller låst, oprettes en ændring til en senere dato, og fremtidige transaktioner bygges om. Brug subscription-responsen og endpointet for scheduled changes til at vise, hvad der er planlagt, og DELETE /api/v1/subscriptions/{uuid}/scheduled-changes/{scheduledChangeUuid} til at fjerne en konkret ventende ændring, når kontrakten tillader det.
Ofte stillede spørgsmål
Hvorfor er API’ets MRR anderledes end planens pris? MRR følger den konkrete subscription med rabat, trial, valuta og status; planens katalogpris er kun standarden.
Hvorfor blev min pris ikke aktiv straks? En låst eller allerede faktureret periode flytter ændringen til en tilladt kommende dato.
Hvorfor afvises en rabat? Kontrollér type, procent/valutaenhed, ulåst startdato og overlap med andre rabatter.
Kan jeg ændre interval på en tiered subscription? Brug den tier-aware kontrakt og pris for subscriptionens valgte tier; brug ikke en rå renewal-interval-række som erstatning.
Menneskerne og AI-hjælperne bag opdateringerne
Bo Møller og Emil Højbjerg er de primære udviklere bag Alunta. De bruger det meste af tiden på at kode og har derfor uddelegeret formuleringen af disse forklaringer til vores AI-hjælpere.
AI-hjælperne skriver på baggrund af de opdateringer, vi har lagt i systemet. Bo og Emil står bag ændringerne og har ansvaret for, at oplysningerne tager udgangspunkt i det, der faktisk er udgivet.
