Hvor meget har vi brugt — og rækker kvoten måneden ud?

Tre steder at læse forbruget

Kvoten på hvert svar

Hvert målt kald har tre headere: X-Quota-Limit er månedens kvote, X-Quota-Remaining er det, der er tilbage, og X-Quota-Reset er unix-tiden for den 1. i næste måned (UTC), hvor kvoten starter forfra. På Enterprise står der unlimited. Du behøver ikke et ekstra kald for at læse dem — tag dem fra de kald, du alligevel laver.

curl -s -D - -o /dev/null "https://api.grundfast.dk/v1/bbr/ejendom/5651067" \
  -H "Authorization: Bearer $GRUNDFAST_API_KEY" | grep -i '^x-quota'
# x-quota-limit: 100000
# x-quota-remaining: 61873
# x-quota-reset: 1793491200

Tælleren bag headerne tæller alle forsøg, også dem, der ender i 400 eller 404 — et afvist kald tæller som ét kald, også når det var et batch-kald. Svar med 5xx og 504 lægges tilbage, og en burst-429 trækker intet. En testnøgle har sin egen kvote på 5.000 kald, og dens svar har X-Grundfast-Environment: test — den rører aldrig kontoens forbrug.

En nøgle, der kun kan læse forbruget

Forbrugs-endpoints under /v1/me/usage svarer kun til dashboardet og til nøgler, der har scopet usage. En almindelig nøgle uden scopes har det ikke — den får 403 — fordi forbruget er kontodata og ikke registerdata. Opret derfor en særskilt nøgle i dashboardet med usage som eneste scope. Den kan læse forbruget og intet andet, så den kan trygt ligge i et overvågningsværktøj. Kaldene til forbrugs-endpoints tæller ikke mod kvoten.

Nøglen sendes som Authorization: Bearer. ?token= og IP-binding virker ikke på kontoens endpoints. Se Begræns en nøgle med scopes.

/v1/me/usage/breakdown?gruppering=noegle er den hurtigste vej til at finde den nøgle, der pludselig bruger meget. SDK’et har den som gf.usageBreakdown().

Hvorfor to tal ikke altid er ens

used fra /v1/me/usage tæller de vellykkede kald i måneden (UTC) — svar under 400. Det er dem, der faktureres. Kvote-headerne tæller også 4xx og, i et batch-kald, hvert unikt id — også dem, der står i errors og ikke faktureres. Derfor kan X-Quota-Limit minus X-Quota-Remaining være lidt højere end used, og forskellen er dine klientfejl og batch-id’er uden svar. Forbruget bliver skrevet med få sekunders forsinkelse, så et kald, du lige har lavet, kan mangle et øjeblik.

Når kvoten er brugt

• Free stopper ved kvoten: kald derefter får 429 resten af måneden.
• Starter, Pro og Scale fortsætter. Vellykkede kald over kvoten koster 1 kr. pr. 1.000 og meldes til faktureringen en gang i timen. overageOre i /v1/me/usage er et overslag i øre, rundet op til nærmeste påbegyndte 1.000 kald.
• Årsplaner har samme månedlige kvote. Overforbruget gøres op ved fornyelsen i stedet for hver måned.
• Enterprise har ingen kvote: allowance er null, og uncapped er true.

Planer og priser står på /priser, og grænserne pr. plan i Rate limits og kvoter.

Besked ved 80 og 100 %

Abonnerer du på usage.threshold, sender Grundfast en hændelse med { tier, threshold_pct, used, allowance, month }, når månedens vellykkede kald passerer 80 % og 100 % af kvoten. Hver grænse sendes højst én gang pr. måned. Forbruget tjekkes en gang i timen, og hver grænse, der er passeret, sendes — springer forbruget fra 70 % til over 100 % inden for samme time, kommer 80 %-hændelsen først og 100 %-hændelsen lige efter. Webhooks er med fra Pro, og Enterprise får ingen, fordi der ikke er en kvote.

Et script, der advarer i tide

En grænse på 80 % kommer ofte for sent, hvis forbruget er steget midt i måneden. Det bedre spørgsmål er: holder vi, hvis de sidste dages tempo fortsætter? Scriptet henter månedens status og dagstallene, regner gennemsnittet af de seneste syv dage og fremskriver det til månedens udgang. Kør det en gang i døgnet fra cron, og send advarslen derhen, hvor jeres drift kigger.

curl "https://api.grundfast.dk/v1/me/usage" \
  -H "Authorization: Bearer $GRUNDFAST_USAGE_KEY"
# {"period":"2026-10","used":38127,"allowance":100000,"uncapped":false,
#  "tier":"starter","overageCalls":0,"overageOre":0}

Skriv advarslen, så den siger, hvad der skal gøres: hvilken nøgle eller hvilket endpoint, der står for stigningen. Et kald til /v1/me/usage/breakdown?gruppering=noegle&range=7d giver svaret. Står forbruget højt fra en enkelt nøgle, er det næsten altid en løkke eller et søgefelt uden debounce — se Hvordan klarer vi os med færre kald?.