Hent MRR inkludert rabatter via API-et
Kunde-API-et viser nå gjeldende og ventende MRR inkludert tidsbegrensede rabatter. De nye feltene effectivemrrbycurrency og effectivependingmrrbycurrency tilsvarer kolonnene «MRR inkl. rabatter» og «Ventende MRR inkl. rabatter» i CSV-eksporten.
Kunde-API-et viser nå gjeldende og ventende MRR inkludert tidsbegrensede rabatter. De nye feltene effective_mrr_by_currency og effective_pending_mrr_by_currency tilsvarer kolonnene «MRR inkl. rabatter» og «Ventende MRR inkl. rabatter» i CSV-eksporten.
Gjeldende og ventende MRR er fortsatt separate: Ventende MRR omfatter abonnementer med fremtidig startdato, aktiv prøveperiode eller aktiv pause. Alle fire API-feltene grupperes etter valuta og bruker minste valutaenhet, som øre eller cent.
Historisk bakgrunn – august 2024 til september 2026
MRR-API-et startet med gjeldende nøkkeltall og ble senere utvidet med ventende verdier, rabatter, intervaller og planlagte endringer. Et svar for et bestemt abonnement er mer relevant enn en planpris i katalogen, fordi abonnementet kan ha sin egen pris, valuta, prøveperiode eller rabatt.
Når en integrator endrer en prøveperiode, rabatt eller fornyelsesintervall, leser du abonnementet tilbake etterpå og skiller mellom en endring som gjelder nå, og en planlagt endring. Bruk UUID-er, paginering og beløpsenheten som er dokumentert i OpenAPI. Se veiledningen for offentlig API og webhooks (Markdown-fil, AI-agentvenlig).
Fra lesing til endring og ny lesing
Start med GET /api/v1/subscriptions/{uuid}. Bruk den fiktive, ikke-eksisterende UUID-en 00000000-0000-4000-8000-000000000003 i et testeksempel. Lagre gjeldende pris, pristype, intervall, prøveperiode og available_price_change_dates før du sender en endring. Send bare handlingen du har tenkt å utføre, og les deretter abonnementsvaret på nytt. API-et returnerer det oppdaterte abonnementet og kan rapportere den faktiske ikrafttredelsesdatoen i meta.effective_date.
Prøveperiode
Bruk PUT /api/v1/subscriptions/{uuid}/trial med { "end_date": "2026-10-15" } for en eksisterende, ulåst prøveperiode. Sluttdatoen må være etter startdatoen for prøveperioden. Et abonnement uten prøveperiode, eller en prøveperiode der transaksjonen allerede er fakturert eller belastet, gir 422; dette kallet oppretter ikke en prøveperiode.
Rabatt
Bruk POST /api/v1/subscriptions/{uuid}/discounts med en dokumentert rabattype. En prosent som 14.29 betyr 14,29 prosent, mens en fast rabatt bruker minste valutaenhet, for eksempel 5000 = 50,00. Rabattperioden må starte i en ulåst periode og kan ikke overlappe med en annen ventende rabatt. Forbruksbaserte abonnementer støtter prosentvise rabatter, mens en fast rabatt blir avvist.
Intervall og pris
PUT /api/v1/subscriptions/{uuid}/interval bruker for eksempel { "interval": 3 }, basert på intervallene som er konfigurert på planen, og trer i kraft fra neste kommende periode. PUT /api/v1/subscriptions/{uuid}/price tar price for abonnementer med fast pris eller unit_price for lisensbaserte abonnementer; ikke bland feltene. Prisendringer gjelder som standard neste periode eller en gyldig effective_date, mens forbruksbaserte priser og nivåbaserte priser følger sine egne prisregler.
En planlagt endring er ikke aktiv ennå. Hvis en periode er fakturert eller låst, flyttes endringen til en tillatt fremtidig dato, og fremtidige transaksjoner bygges på nytt. Bruk abonnementsvaret og endepunktet for planlagte endringer til å vise hva som er planlagt, og bruk DELETE /api/v1/subscriptions/{uuid}/scheduled-changes/{scheduledChangeUuid} for å fjerne en bestemt ventende endring når kontrakten tillater det.
Ofte stilte spørsmål
Hvorfor er MRR fra API-et forskjellig fra planprisen? MRR følger det bestemte abonnementet, med rabatt, prøveperiode, valuta og status; planprisen i katalogen er bare standardverdien.
Hvorfor ble ikke prisen aktiv umiddelbart? En låst eller allerede fakturert periode flytter endringen til en tillatt fremtidig dato.
Hvorfor blir en rabatt avvist? Kontroller type, prosent eller valutaenhet, ulåst startdato og overlapp med andre rabatter.
Kan jeg endre intervallet på et nivåbasert abonnement? Bruk den nivåtilpassede kontrakten og prisen for abonnementets valgte nivå; ikke sett inn en rå rad for fornyelsesintervall.
Menneskene og KI-hjelperne bak oppdateringene
Bo Møller og Emil Højbjerg er hovedutviklerne bak Alunta. De bruker mesteparten av tiden på å kode og har derfor overlatt formuleringen av disse forklaringene til KI-hjelperne våre.
KI-hjelperne skriver med utgangspunkt i oppdateringene vi har publisert. Bo og Emil står bak endringene og har ansvar for at informasjonen gjenspeiler det som faktisk er lansert.
