A&G Partner API

Version 1.3.0 - 30. oktober 2026

Datakald kræver en aktiv, godkendt API-nøgle. Dokumentationen indeholder ingen adgangsnøgler.

1. Adgang og adresser

API: https://supplier-api.aogg.dk. Partnerportal: https://portal.aogg.dk. Administration: https://intern.aogg.dk/api-adgange. Interaktiv dokumentation: https://supplier-api.aogg.dk/docs. OpenAPI: https://supplier-api.aogg.dk/openapi.json. Dokumentationsversion 1.3.0, kontrolleret mod installeret API-kode 30. oktober 2026.

2. Aktuel status

HTTPS er installeret. API-adgang aktiveres særskilt pr. godkendt leverandør. Dokumentation er offentligt læsbar og indeholder ingen nøgler, kundeoplysninger eller faktiske salgsudtræk. Dokumentationen udleverer ingen adgang i sig selv. Brug kun en nøgle, som A&G har udstedt til den konkrete leverandør. Testresultater og aktivering bekræftes separat ved nøglelevering.

3. Sikkerhed og rettigheder

Send API-nøglen i headeren X-API-Key over HTTPS. Nøglen identificerer en leverandørintegration, ikke nødvendigvis en bestemt medarbejder. API'et kontrollerer nøglens hash, aktiv status, udløb og leverandørens aktive status. Datakald kontrollerer også salg/lager-tilladelse samt butiksadgang. Kun GET er tilladt på de publicerede dataendepunkter. Gem nøgler i en sikker hemmelighedstjeneste; brug ikke URL-parametre, kildekode eller almindelig e-mail. Microsoft-login til portalen er separat fra denne API-nøgle. Nøgleadministrationen kræver den godkendte administratoridentitet.

4. Endepunkter

GET /v1/me: leverandøridentitet. GET /v1/sales: salgsdata i valgt periode. GET /v1/inventory: seneste komplette lageropgørelse pr. godkendt butik. Alle tre kræver X-API-Key. Den tidligere adresse portal.aogg.dk/api/v1/... er bevaret under overgangen. Brug den nye adresse i nye integrationer. Der er ingen ordreoprettelse, ændring af varer eller personlige kundehistorikker i denne API-kontrakt.

5. Salg: parametre

from_date og to_date er påkrævede datoer i formatet YYYY-MM-DD. Fra-dato må ikke være efter til-dato; datoer må højst ligge tre kalenderår tilbage og ikke i fremtiden. Intervallet er tiltænkt inklusive begge datoer. API-validering bruger Europe/Copenhagen; en fuld afstemning af datakildens tidsstempler ved midnat er fortsat et kontrolpunkt. shop_id er valgfri. Udeladt shop_id giver alle tilladte butikker, ikke alle A&G-butikker uden adgangskontrol.

6. Butikker og paginering

Butiks-ID: Skive 367001, Viborg 367003, Silkeborg 367004. Tilgængelighed afhænger af den konkrete leverandørs aftale og historik. limit: standard 100, minimum 1, maksimum 1000. offset: standard 0, minimum 0, maksimum 100000. Begge dataendepunkter bruger disse parametre. Hent næste side ved at lægge limit til offset, og stop når en side har færre rækker end limit. count er antal rækker på siden, ikke antal rækker i hele perioden. Der er ingen dokumenteret stabil udtrækstransaktion på tværs af sider; indlæsninger under et langt udtræk kan ændre datagrundlaget. Afstem store udtræk og opdel perioder ved offset-grænsen.

7. Salgsfelter og moms

Svaret har supplier, supplier_id, from_date, to_date, count og sales. Hver salgsrække har shop_id, sales_date, item_number, ean, quantity og net_sales. quantity er netto antal med fortegn på returneringer. net_sales er et linjebeløb efter rabatter og retur, inklusive moms, i DKK. Navnet net_sales betyder her ikke omsætning eksklusive moms. Beløbet må ikke multipliceres med quantity igen. Summer net_sales for det ønskede udvalg. Bevar EAN og varenumre som tekst, så foranstillede nuller ikke går tabt. Historiske EAN-koder kan være A&G-interne og kan ikke uden en dokumenteret kobling sidestilles med leverandørens originale koder. En datoafgrænsning fjerner ikke automatisk gamle koder, der fortsat sælges.

8. Lager: felter og aktualitet

Svaret har supplier, supplier_id, count, limit, offset, positive_only og inventory. Rækker har shop_id, snapshot_time, style_id, variant_id, ean, item_group_id og stock_quantity. positive_only=true er standard og viser kun positive beholdninger; false medtager også nul og negative poster. snapshot_time er opgørelsens tidspunkt med tidszone, ikke nødvendigvis tidspunktet for kaldet. Lager er en opgørelse, ikke garanteret disponibelt live-lager. Style-ID må ikke automatisk sidestilles med salgssidens varenummer. Kostpris og lagerværdi er ikke felter i det publicerede v1.3-lagersvar.

9. Fejlkoder

200: opslag gennemført. 400: ugyldig salgsperiode. 401: nøgle mangler, er ugyldig, spærret eller udløbet, eller leverandøren er deaktiveret. 403: butik/datatype er ikke tilladt; skriveforsøg kan også afvises ved webserveren. 422: parameterformat eller grænse er forkert. 503: midlertidig fejl i adgangsdatabase eller datakilde. Webserveren kan også returnere 502/504 ved backendfejl eller timeout. Nul rækker beviser ikke, at der ingen handel var; kontrollér datadækningen. /v1/me har fortsat data_access=false som et historisk felt, der ikke skal bruges som rettighedsindikator.

10. Drift, opdatering og begrænsninger

API'et læser A&G's Azure-datagrundlag; et API-kald udløser ikke et nyt opslag hos DdD. Aktuel datadækning og lagerets snapshot skal kontrolleres. Der er ikke aftalt en garanteret opdateringsfrekvens, svartid eller en offentlig 429/rate-limit-kontrakt. Kør sekventielt med passende pauser og begrænsede sider. Ved 503/502/504 kan integrationen forsøge igen med stigende ventetid og et fast maksimum; ved 401/403 skal adgangen afklares. Log ikke nøgler eller fulde persondata. Nye funktioner som automatisk førstegangs-mail og detaljeret API-brugslog skal først beskrives som driftssatte, når de er særskilt verificeret.

11. Nøglers levetid og tilbagekaldelse

Administrator kan spærre enkelte nøgler eller hele leverandøradgangen. Spærring kontrolleres ved nye API-kald; et allerede gennemført eller igangværende svar kan ikke trækkes tilbage. Nøgler udleveres separat og vises kun ved oprettelse/fornyelse. Standardgyldigheden for nye nøgler er 36 kalendermåneder. Ved samarbejdets ophør skal leverandøradgangen straks spærres manuelt, uanset udløbsdato. Der er ingen automatisk udløbspåmindelse eller nøglefornyelse. Gyldighed og aktivering fremgår af den separate nøglelevering. Ved mistanke om læk skal nøglen spærres straks.

12. Test og integration

Importér openapi.json i et OpenAPI-kompatibelt værktøj, eller åbn Swagger-visningen og brug Authorize. Browseren gemmer ikke nøglen ved genindlæsning. Brug kun Try it out med særskilt godkendt nøgle; en spærret eller udløbet nøgle bliver afvist. Test først /v1/me, derefter fem salgs- og lagerposter, butiksbegrænsning, en forkert nøgle, returvarer og paginering. Sammenhold beløb med en kendt periode. Test af adgang må ikke forveksles med en sikkerhedstest, belastningstest eller komplet regnskabsafstemning.

13. Versionsstyring og kilder

OpenAPI-filen bygger på de installerede FastAPI-ruter og er beriget med feltdefinitioner fra den eksisterende API-dokumentation og kontroludtræk. PDF, fil og webside er samme dokumentationsleverance, dateret 30. oktober 2026. Ved ændringer i API-parametre, felter eller betydning skal alle formater opdateres sammen. OpenAPI-baggrund: https://swagger.io/docs/specification/v3_0/about/. Support og aktivering aftales med A&G; send HTTP-status, tidspunkt, sti og parametre, men aldrig selve API-nøglen.

PowerShell - fem salgsrækker

$secret = Read-Host "API-nøgle" -AsSecureString
$credential = [PSCredential]::new("api", $secret)
$headers = @{ "X-API-Key" = $credential.GetNetworkCredential().Password.Trim() }
try {
    $base = "https://supplier-api.aogg.dk"
    $uri = "$base/v1/sales?from_date=2026-10-01&to_date=2026-10-29&limit=5&offset=0"
    $result = Invoke-RestMethod -Uri $uri -Headers $headers -ErrorAction Stop
    $result | ConvertTo-Json -Depth 10
} catch {
    Write-Host $_.ErrorDetails.Message
} finally {
    $headers.Clear()
    Remove-Variable credential, secret -ErrorAction SilentlyContinue
}