Guider

Saldo

Saldo, rörelsehistorik och skattemässiga underlag läser du både via API och via MCP. Kortbetalning - engångs eller automatisk - går alltid via en länk till Stripe Checkout som en människa slutför; API:et debiterar aldrig kortet på egen hand. Detsamma gäller det valfria månadsabonnemanget.

Pengar utan moms, heller, beskrivningarnas språk

Alla belopp i det här API:et är heltal i HELLER och utan moms - volai är momsregistrerat, men momsen beräknas först när saldot fylls på med kort (översikt på /cenik). Beskrivningarna av rörelser (GET /v1/credit/ledger) sätter API:et ihop på engelska utifrån rörelsens typ - en sparad tjeckisk anteckning lämnar aldrig systemet, inte heller i något annat fält.

Saldo, räckvidd och avisering

GET /v1/balance returnerar det aktuella saldot plus två kompletterande beräkningar ADDITIVT (befintliga klienter som bara läser balanceHal/balanceCzk/currency går inte sönder): runway (dailyAverageHal - genomsnittlig daglig förbrukning under den senaste tiden, runwayDays - hur många dagar saldot räcker i den här takten, null när det inte går att beräkna) och notice - samma avisering som visas på /prehled i portalen, null när det inte finns någon. Åtta möjliga former av notice: {kind:"unknown"} (för lite data för en uppskattning), {kind:"empty"} (saldot är noll), {kind:"number_fee",feeHal,dueAt} (inom 3 dagar förfaller en månadsavgift för röst- eller mobilnummer och saldot räcker inte till den; feeHal är summan av alla sådana avgifter, dueAt det tidigaste förfallodatumet; returneras inte när automatisk påfyllning är på), {kind:"runway",days} (saldot tar slut om days dagar i nuvarande takt) och fyra former bara för konton med månadsabonnemang: {kind:"subscription_exhausted_topup",renewsAt} (periodens månadssaldo är förbrukat och abonnemanget körs i läget påfyllning, så att fortsatt förbrukning tas från påfyllt saldo; renewsAt är periodens slut i ms, när nytt månadssaldo tillskrivs), {kind:"subscription_cap_reached",renewsAt} (månadssaldot är förbrukat, abonnemanget körs med tak och påfyllt saldo täcker ingenting, betalda åtgärder stoppas till renewsAt eller till manuell påfyllning) och {kind:"subscription_past_due"} (förnyelsen av abonnemanget gick inte igenom, det sparade kortet kunde inte debiteras; förnyelsen betalar du i portalen eller så byter du kort) och {kind:"subscription_runway",renewsAt,runsOutAt} (saldot tar slut innan nytt månadssaldo tillskrivs vid renewsAt; runsOutAt är en uppskattning i ms av när det tar slut, utifrån abonnemangets försiktiga takt, samma som prognosen för månadssaldot på abonnemangskortet i portalen: det högsta av genomsnittet för 28 dagar (bara vid fullständig saldohistorik), genomsnittet av driften de senaste 7 dagarna i Prag utan nummeravgifter och genomsnittet sedan periodens början (först efter dess första vecka); runway räknar fortfarande med genomsnittet för 28 dagar; returneras i stället för runway för en abonnent och returneras inte när automatisk påfyllning är på). renewsAt är i ms (epoch), alltså samma tidpunkt som subscription.periodEnd i samma svar, där den är en ISO 8601-sträng; formatet på något av fälten ändras inte. För ett abonnemang som sägs upp vid periodens slut har subscription_exhausted_topup, subscription_cap_reached och subscription_runway dessutom cancelAtPeriodEnd: true: ingen förnyelse kommer, renewsAt är abonnemangets slut och nytt månadssaldo tillskrivs inte (med tak går det då bara att fortsätta genom påfyllning); utan uppsägning finns fältet inte i aviseringen. För ett konto med månadsabonnemang innehåller svaret dessutom subscription (abonnemangets status, annars null) och topupBalanceHal (bara påfyllt saldo); balanceHal är fortfarande summan av månadssaldo och påfyllt saldo, se kapitlet Månadsabonnemang.

Rörelsehistorik

GET /v1/credit/ledger?limit - de senaste rörelserna först, UTAN markör (bara limit, 1-200, standard 50) - äldre rörelser än de 200 senaste når du inte via API:et, hela historiken finns i portalen under /kredit och bland de skattemässiga underlagen. Varje post har type (bonus, topup, call_out, call_in, sms, number_fee, agent, refund, admin, setup_revision - en omgång ändringar i en beställning med Nyckelfärdigt utöver paketet, subscription_grant - tillskrivning av månadssaldo från abonnemanget och subscription_expire - förfall av dess outnyttjade rest), amountHal (positivt tillägg, negativt avdrag), grossHal (belopp inklusive moms vid påfyllning med kort, annars null) och en engelsk description sammansatt av typen - för number_fee dessutom med numret som avgiften avser. För förbrukning som täckts av månadssaldo finns dessutom fältet fromSubscriptionHal - den del av förbrukningen som månadssaldot täckte; för övriga rörelser saknas det. Tillägget mobilnummer syns i historiken som number_fee (första perioden vid köpet och varje förnyelse efter 30 dagar) och sms (utskick från mobilnumret, taxan per segment finns i prislistan); om operatören i efterhand avvisar ett sms från mobilnumret återförs saldot med posten refund.

Påfyllning med kort

POST /v1/credit/topup {amountCzk} returnerar {checkoutUrl} - en Stripe Checkout-länk som en MÄNNISKA öppnar i webbläsaren. Inget debiteras förrän hen själv slutfört betalningen. Faktureringsadressen (PUT /v1/account/billing) måste vara komplett INNAN anropet - utan den går det inte att utfärda ett giltigt skattemässigt underlag (billing_address_required). Stöder Idempotency-Key - det är säkert att upprepa efter en timeout utan att två betalningar uppstår.

Automatisk påfyllning

Via API:et går automatisk påfyllning bara att LÄSA, STÄNGA AV och ändra TRÖSKELN - att slå på den och ändra BELOPPET går uteslutande via Stripe Checkout, aldrig genom en direkt skrivning.

Läsning och avstängning

GET /v1/credit/auto-topup returnerar {enabled, thresholdHal, amountHal, card: {brand, last4} | null, spentThisMonthHal, monthlyCapHal, disabledReason} - UTAN kortnumret, bara märket och de fyra sista siffrorna. PATCH {enabled: false} stänger av direkt, PATCH {thresholdHal} ändrar bara tröskeln (den måste vara ur den erbjudna serien och lägre än det sparade beloppet, annars hamnar saldot direkt under tröskeln igen efter påfyllningen).

Påslagning och ändring av belopp

POST /v1/credit/auto-topup/setup {thresholdHal, amountHal} returnerar {checkoutUrl} - när Checkout är slutförd debiteras OMEDELBART amountHal som första påfyllning, och först då sparas kortet för framtida automatiska påfyllningar. Fungerar även med ett kort som redan sparats tidigare - det är den enda vägen att slå på automatisk påfyllning eller ändra beloppet. När Checkout är slutförd återvänder webbläsaren till den TJECKISKA sidan i portalen (/kredit?automat=zapnuto) även för en engelsktalande kund - ett känt gap, inte ett fel i din integration.

Kort

POST /v1/credit/auto-topup/card returnerar en Checkout-länk (kortbytesläge, inget debiteras) för att byta det sparade kortet. DELETE /v1/credit/auto-topup/card kopplar bort kortet OMEDELBART - hela konfigurationen raderas (både tröskel och belopp), inte bara kortet; nästa påslagning går bara via .../setup igen, som genast debiterar den första påfyllningen. När Checkout är slutförd återvänder webbläsaren till den TJECKISKA sidan i portalen (/kredit?karta=zmenena) oavsett kontots språk - samma kända gap som ovan.

Tak

Två OBEROENDE tak: högst 10 000 CZK tillskrivet saldo per kalendermånad och högst 4 påfyllningar per KALENDERDAG - oavsett hur många gånger tröskeln underskrids. Om något av dem överskrids stänger den automatiska påfyllningen av sig själv (disabledReason monthly_cap respektive daily_cap); spentThisMonthHal/monthlyCapHal i svaret visar hur mycket av månadstaket som återstår.

MCP: get_auto_topup (läsning) och disable_auto_topup (avstängning) - påslagning, ändring av belopp och kort finns inte i MCP, av samma skäl som enabled: true i REST ovan.

Månadstak för förbrukning

En valfri säkring mot en oväntat hög räkning: du ställer själv in hur mycket samtal, sms och röstagent får kosta per kalendermånad (enligt tiden i Prag). Funktionen är bara på för ett konto som har ställt in ett tak; utan tak ändras ingenting och månadens förbrukning räknas bara.

GET /v1/account/spend-cap returnerar {spendCap: {enabled, capHal, warnShare, inboundAboveCap, month, monthSpendHal, remainingHal, reached, updatedAt}}. Utan tak är enabled: false och taksfälten null, men monthSpendHal får du alltid. Beloppen är i hela heller utan moms.

PUT /v1/account/spend-cap {capHal, warnShare?, inboundAboveCap?} ställer in eller ändrar taket: capHal är i hela heller från 5 000 (50 CZK) till 100 000 000 (1 000 000 CZK), warnShare är den andel av taket från 0,5 till 0,99 (standard 0,8) då varnings-e-posten skickas, och inboundAboveCap: true låter agenterna fortsätta ta emot inkommande samtal även över taket (standard false, vid ändring utan fältet gäller det sparade värdet). DELETE /v1/account/spend-cap tar bort taket; att ta bort ett tak som inte finns är i sin ordning.

När taket är nått avvisas nya utgående samtal, uppringningar, testsamtal och sms med koden spend_cap_reached (HTTP 402), inget debiteras och ett nytt försök hjälper inte förrän månaden är slut eller taket höjs eller tas bort. Ett inkommande samtal till agenten avslutas efter en mening och kostar ingenting, om inte inboundAboveCap: true är satt. E-post skickas när warnShare nås och när taket nås, alltid högst en gång per månad.

Vad taket INTE stoppar: samtal som pågår just nu (priset debiteras först efter samtalet, så månaden kan sluta med deras pris över taket, på samma sätt som för samtal som bokförs efter midnatt), vidarekoppling utan agent samt nummeravgifter, en omgång ändringar i Nyckelfärdigt och månadsabonnemanget, som inte räknas in i taket. För ett konto med abonnemang räknas även det som månadssaldot täckte in i förbrukningen. Ett nummer i Egen SIP-växel med inboundAboveCap: true ligger kvar i SIP-proxyn, så taket stoppar inte utgående samtal från växeln.

MCP: get_spend_cap, set_spend_cap och clear_spend_cap anropar samma tjänst som REST och portalen (avsnittet Månadstak för förbrukning under Saldo). set_spend_cap ska upprepa beloppet för kunden både före och efter skrivningen.

Månadsabonnemang

Valfri prenumeration: varje månad debiteras priset för den valda nivån från det sparade kortet och ett månadssaldo i CZK tillskrivs, som förbrukas enligt den vanliga prislistan. Taxorna och debiteringen per sekund ändras inte av det, abonnemanget är ett lager ovanpå dem. Det finns tre nivåer och tier är deras pris i CZK utan moms: "490", "990" och "1990"; priser och saldo för varje nivå returneras av GET /v1/subscription i fältet tiers.

Två slags saldo

Månadssaldo kommer från abonnemanget, förfaller vid periodens slut och återbetalas inte. Påfyllt saldo (påfyllning, välkomstbonus, korrigering) förfaller inte och är återbetalningsbart som tidigare. Kontots saldo - balanceHal i GET /v1/balance, i portalen och i alla spärrar (minimum för samtal, skuldgräns, varning) - är summan av båda slagen. Enbart påfyllt saldo finns i topupBalanceHal, kvarvarande månadssaldo i subscription.monthlyRemainingHal. Skuld kan bara uppstå i påfyllt saldo.

Ordningen för förbrukning

Varje förbrukning tas först från månadssaldot och resten från påfyllt saldo - samtal per sekund, agent, avgifter för nummer och mobilnummer, sms, uppringningar och utgående uppgifter. Fördelningen är atomär och skrivs i huvudboken: en förbrukning som täckts av månadssaldo har fromSubscriptionHal (den del som månadssaldot täckte). Korrigeringar från ägaren (admin, även negativa) och återbetalning för ett sms som inte skickats (refund) gäller bara påfyllt saldo.

Period och tillskrivning

Perioden varar en månad från den lyckade debiteringen (31.1. ger 28.2.). Månadssaldot tillskrivs först efter en bekräftad betalning med posten subscription_grant, och tillskrivningen är idempotent per betalnings-id. Om kontot just då har en skuld i påfyllt saldo betalas den först från det nya månadssaldot, så att det påfyllda saldot inte blir negativt.

Förfall

Den outnyttjade resten av månadssaldot förfaller på förnyelsedagen (posten subscription_expire med ett negativt belopp), när prenumerationen upphör, eller genom en automatisk säkring när perioden tog slut för mer än 36 timmar sedan utan förnyelse. Om debiteringen inte går igenom har resten redan förfallit och inget nytt saldo tillskrivs; fram till betalning körs kontot bara på påfyllt saldo.

Val när saldot är förbrukat

Vid påslagning måste exhaustionMode väljas, utan förval. topup: när månadssaldot är förbrukat fylls påfyllt saldo på från det sparade kortet - det är dagens automatiska påfyllning med samma gränser och e-postmeddelanden. cap (tak): inget fylls på, utgående samtal, sms och nummerköp avvisas med felet subscription_cap_reached (HTTP 402), och vid ett saldo under noll stoppas även inkommande samtal, vidarekoppling och SIP-åtkomst (stopp vid noll, återställs efter påfyllning eller med nytt månadssaldo). Med tak går det inte att slå på automatisk påfyllning (subscription_cap_active); att byta till tak stänger av den. Det mesta du betalar per månad med tak är abonnemangets pris.

Byte av nivå, uppsägning, återupptagande

Byte av nivå (uppåt och nedåt) gäller från nästa period, utan avräkning. Uppsägning är cancelAtPeriodEnd: true: saldot gäller till periodens slut, förfaller sedan och statusen blir canceled; fram till periodens slut går uppsägningen att ta tillbaka. Via REST och MCP går det inte att höja nivån, återuppta ett uppsagt abonnemang eller byta till påfyllning från kortet - de stegen ökar eller slår på nytt återkommande debiteringar, så de returnerar subscription_confirmation_required med en confirmUrl som en människa öppnar och bekräftar i portalen (gäller i 24 timmar).

Råd före förnyelsen

Tre dagar före förnyelsen (senast dagen före) skickas ett e-postmeddelande, men bara om det med den hittillsvarande förbrukningen skulle bli billigare att betala per sekund eller att ha en lägre nivå. Samma regel gäller som för rådet i e-postmeddelandet om förnyelsen och i portalen: en annan väg måste bli minst 50 CZK och 5 % billigare. Uppskattningen för hela perioden tar det högre av takterna sedan periodens början och för de senaste 7 dagarna och är aldrig lägre än förbrukningen de senaste 30 dagarna, som portalen ger råd utifrån; raderna Nivå och Uppsägning säger därför inte efter ett klick att nivån passar. E-postmeddelandet anger exakt datum och tid för förnyelsen och skickas högst en gång per period, aldrig för ett abonnemang som sagts upp vid periodens slut, med ett planerat nivåbyte, utan sparat kort eller som väntar på betalning. Knappen i det öppnar i portalen direkt raden Uppsägning (/kredit?pausal=zrusit) eller Nivå (/kredit?pausal=stupen). E-postmeddelandet om förnyelsen ger sedan råd på nytt utifrån den faktiska förbrukningen under hela perioden, så rådet kan bli ett annat.

Obetald förnyelse

Debiteringen från det sparade kortet prövas på förnyelsedagen, efter 2 och efter 4 dagar. Efter det första misslyckandet är statusen past_due, ett e-postmeddelande med en länk till manuell betalning och till byte av kort skickas och månadssaldot är 0; den manuella betalningen returneras av POST /v1/subscription/pay. Efter det tredje misslyckandet upphör abonnemanget (canceled), påfyllt saldo och kontot fortsätter att fungera.

Moms och underlag

Priserna är utan moms. Momsregimen läses före varje debitering, så en betalare från ett annat EU-land med verifierat momsnummer betalar utan tjeckisk moms (reverse charge) och underlaget speglar det. Det skattemässiga underlaget för varje betald period utfärdar volai självt (beskattningsunderlaget är nivåns pris, inte det tillskrivna saldot) och du hittar det i GET /v1/billing/documents.

Förhållande till bonus och första påfyllning

Att slå på abonnemanget räknas som första betalning: det låser upp sms från den delade avsändaren, vidarekoppling, ett andra nummer, mobilnummer och kortet för automatisk påfyllning på samma sätt som en påfyllning. Välkomstbonusen förblir påfyllt saldo.

Återbetalning

Månadssaldot är inte återbetalningsbart och förfaller; påfyllt saldo är återbetalningsbart som tidigare. Uppsägning av abonnemanget ger ingen rätt till en proportionell del av den betalda perioden. Återbetalning av en abonnemangsbetalning (reklamation, misstag) hanteras manuellt av volais ägare, det går inte via API eller MCP.

Abonnemang i REST och MCP

Pengar rör sig bara med en människa vid kortet. Påslagning av abonnemanget och manuell betalning returnerar bara en länk till Stripe Checkout och debiterar aldrig kortet direkt; höjning av nivån, återupptagande av ett abonnemang som ställts in att sluta vid periodens slut och byte till påfyllning från kortet kräver bekräftelse från en inloggad människa i portalen.

• GET /v1/subscription - abonnemangets status (subscription eller null), katalogen över nivåer tiers (id, priceHal, creditHal), topupBalanceHal, available (ett nytt abonnemang kan slås på: erbjudandet är på och inget abonnemang pågår), recommendation (den billigaste vägen för förbrukningen de senaste 30 dagarna och steady, om förbrukningen är bestående och inte bara en engångstopp; null utan erbjudande eller utan 30 dagars historik) och previousPeriod (föregående period med samma siffror som i e-postmeddelandet om förnyelsen: usedHal av creditHal, usedPercent, förbrukning över månadssaldot overHal och förfallen rest expiredHal; bara för ett aktivt abonnemang, null i den första perioden och när förbrukningen inte kan styrkas ur historiken).
• POST /v1/subscription/checkout {tier, exhaustionMode, consumerConsent?} - returnerar {checkoutUrl} till Stripe Checkout, och när den är slutförd startar abonnemanget. exhaustionMode (topup eller cap) är obligatoriskt; en konsument utan IČO måste skicka consumerConsent: true (annars consumer_consent_required). Faktureringsadressen måste vara komplett (billing_address_required). Stöder Idempotency-Key.
• PATCH /v1/subscription {tier?, cancelAtPeriodEnd?, exhaustionMode?} - sänkning av nivå, uppsägning (cancelAtPeriodEnd: true) och byte till tak (exhaustionMode: "cap") utförs och {subscription} returneras. Höjning av nivå, återupptagande av ett abonnemang som ställts in att sluta vid periodens slut (cancelAtPeriodEnd: false) och exhaustionMode: "topup" ändrar ingenting och returnerar 409 subscription_confirmation_required med confirmUrl.
• POST /v1/subscription/pay - bara i statusen past_due; returnerar {checkoutUrl} för manuell betalning av förnyelsen. Stöder Idempotency-Key.
• POST /v1/subscription/card - returnerar {checkoutUrl} för byte av abonnemangets sparade kort, inget debiteras. Stöder Idempotency-Key.
• GET /v1/balance har dessutom subscription (samma form som ovan, annars null) och topupBalanceHal.

MCP: get_subscription (läsning), create_subscription_link (länk för påslagning), update_subscription och cancel_subscription (sänkning av nivå, uppsägning, tak; höjning, återupptagande och påfyllning returnerar confirmUrl med en mening om att en människa måste bekräfta det i portalen) och create_subscription_payment_link (manuell betalning). Byte av kort finns inte i MCP, av samma skäl som för automatisk påfyllning: härifrån debiteras ingenting.

Skattemässiga underlag

Underlaget uppstår automatiskt vid påfyllning av saldo med kort (både engångs och automatisk), vid betalning av uppstarten av Nyckelfärdigt och som rättelseunderlag när uppstarten återbetalas - inget manuellt steg, ingen utfärdning via API.

GET /v1/billing/documents?limit&before - de senaste först, markören before (Unix ms, exklusiv) är nextBefore från föregående sida. Lagringen returnerar själv aldrig fler än 100 poster per anrop, även om limit begär fler.

GET /v1/billing/documents/{id} returnerar {id, number, issuedAt, taxableAt, netHal, vatHal, grossHal, vatRatePercent, reverseCharge, description, customer, paymentRef, pdfUrl} - reverseCharge: true för betalare från ett annat EU-land med verifierat momsnummer (VIES), som betalar utan tjeckisk moms. Fältet kind är alltid ifyllt - "invoice" för ett vanligt underlag (även för underlag som utfärdats innan fältet infördes), "credit_note" för ett rättelseunderlag - det uppstår automatiskt när ägaren återbetalar priset för uppstarten vid en avbruten beställning av Nyckelfärdigt, numreras i en egen serie OD... och har dessutom correctsNumber (numret på det rättade underlaget) och correctionReason (orsaken till återbetalningen); beloppen netHal/vatHal/grossHal är POSITIVA även för en kreditnota, minustecknet sätts först av PDF:en.

GET /v1/billing/documents/{id}/pdf laddar ner samma underlag som application/pdf - det sätts färskt vid varje nedladdning och lagras inte. Ett främmande eller obefintligt id ger samma fel (invoice_not_found) i båda endpoints, så att det inte går att utläsa av svaret att ett främmande underlag finns.

MCP: list_billing_documents och get_billing_document har samma form som REST. PDF finns bara i REST - MCP har ingen binär kanal för filöverföring.

Fel

• ledger_unavailable - Rörelsehistoriken och saldot går inte att läsa för tillfället - försök igen om en stund.
• invalid_amount - Beloppet för påfyllning, tröskel eller automatisk betalning är inte ett av de erbjudna fasta värdena.
• billing_address_required - Faktureringsadressen saknas eller är ofullständig - komplettera den i portalen (/nastaveni) före påfyllningen, annars går det inte att utfärda ett giltigt underlag.
• stripe_not_configured - Betalningar är avstängda för den här körningen av volai - gäller inte specifikt din begäran.
• stripe_error - Stripe avvisade att skapa en betalningssession - försök igen om en stund.
• autotopup_not_configured - Automatisk påfyllning har aldrig gått igenom .../setup - det finns inget att stänga av, ändra eller något kort att byta.
• invoice_not_found - Det finns inget underlag med det här id på kontot (eller så tillhör det ett annat konto - svaret är detsamma).
• spend_cap_reached - Månadstaket för förbrukning som du har ställt in är nått: nya utgående samtal och sms avvisas och inget debiteras. Taket höjer eller tar du bort via PUT eller DELETE /v1/account/spend-cap, annars gäller det till månadens slut (till midnatt i Prag).
• subscription_cap_reached - Abonnemangets tak: både månadssaldot och det påfyllda saldot är förbrukade och kontot har valt tak. Utgående samtal, sms och nummerköp avvisas (HTTP 402) till nästa förnyelse eller till manuell påfyllning.
• subscription_exists - Kontot har redan ett abonnemang; byte av nivå, uppsägning och val när saldot är förbrukat går via PATCH /v1/subscription.
• subscription_missing - Kontot har inget aktivt abonnemang som kan ändras, sägas upp eller betalas manuellt.
• subscription_canceled - Abonnemanget har redan upphört (status canceled): det kan inte ändras, sägas upp eller betalas manuellt. Ett nytt slår du på via POST /v1/subscription/checkout.
• subscription_confirmation_required - Höjning av nivå, återupptagande av ett abonnemang som ställts in att sluta vid periodens slut och påfyllning från kortet bekräftas bara av en människa i portalen - svaret har confirmUrl och ingenting har ändrats.
• consumer_consent_required - En konsument utan IČO måste vid påslagning bekräfta en uttrycklig begäran om att påbörja fullgörandet innan ångerfristen löpt ut (consumerConsent: true).
• pausal_unavailable - Abonnemangserbjudandet är just nu avstängt för det här kontot.
• invalid_tier - Nivån som abonnemanget redan har när ingen annan är planerad (en nivå som abonnemanget redan är på väg att byta till är inget fel och räknas som utförd, så samma PATCH /v1/subscription kan skickas igen efter ett avbrott; ett undantag är återgång till dagens nivå, som avbryter ett planerat byte: vid upprepning finns inget kvar att avbryta); ett okänt värde utanför "490", "990", "1990" slutar som validation.
• subscription_cap_active - Med tak går det inte att slå på automatisk påfyllning; byt först valet när saldot är förbrukat till topup i portalen.
• validation - Specifikt för PATCH /v1/credit/auto-topup: ett försök att slå på (enabled: true) eller ändra amountHal direkt - använd POST .../setup i stället.

Den fullständiga tabellen över fel för varje endpoint finns i avsnittet Saldo i REST API-referensen.