GETHent appens egen operationskvittering

Formål og præcis afgrænsning

Hent en enkelt kvittering for en operation udført af samme app under samme organisation og samme grant. Brug operation_id fra et tidligere svar til at finde operationstype, registreret HTTP-status, det minimale resultat og tidspunktet.

Dette endpoint er ikke en generel søgning i kundens aktivitet. En kvittering kan ikke læses alene ved at kende dens UUID. Både tokenet og operations:read skal være gyldige, og kvitteringens adgangskontekst skal passe. En afvist eller tilbagekaldt grant giver ikke en særskilt nødadgang til tidligere svar.

Før kaldet

Vælg den eksplicit konfigurerede installation. HOURS_BASE er enten dens /api/partner/sandbox/v1 eller /api/partner/v1. Basisadressen vises i App Console for appen. Et sandboxtoken begynder med hsk_; et produktions-access-token begynder med hat_. De er ikke indbyrdes udskiftelige og er ikke Supabase-login-tokens.

Produktion kræver en godkendt apprevision, en kundegrant og de relevante scopes. Kundegrantet er givet af organisationsejeren med tofaktor (aal2), gælder de valgte konti og varer højst 90 dage. Endelig journalbogføring kræver et særskilt mandat. Sandbox kræver en klargjort appgeneration i et separat projekt. En gyldig tokenform alene er ikke adgang.

Input og grænser

Ukendte og gentagne queryparametre afvises. En teknisk reference er ikke et bevis på ejerskab. Kaldet filtreres og autoriseres ud fra serverens gemte kontekst, ikke ud fra en valgfri klientheader med kunde-id.

Eksempel

Indstil HOURS_BASE og HOURS_TOKEN fra den aktive, autoriserede kontekst. Ved kvitteringsopslag sættes OPERATION_ID til det ID, din egen operation returnerede.

curl --silent --show-error --fail-with-body \
  --request GET "$HOURS_BASE/operations/$OPERATION_ID" \
  --header "Authorization: Bearer $HOURS_TOKEN"

Succes og output

Forvent HTTP 200 ved succes:

{
  "id": "00000000-0000-4000-8000-000000000900",
  "operation": "products.create",
  "http_status": 201,
  "result": {
    "id": "00000000-0000-4000-8000-000000000200",
    "created": true
  },
  "created_at": "2026-09-30T08:00:00Z"
}

Svaret skal fortolkes som den beskrevne projektion. Det giver ikke ekstra rettigheder eller en komplet kopi af den interne model. Bevar især forskellen på lokal inputkontrol, kvittering og aktuel regnskabstilstand.

Fejl og genforsøg

Manglende eller forkert miljøtoken afvises. Manglende scope, tilbagekaldt grant eller ændret apprevision stopper kaldet. Reference- og domænefejl skal afklares i stedet for at blive omskrevet til tilfældige gyldige værdier.

Ved midlertidig transportfejl kan det samme læse- eller prepare-kald forsøges igen under aktuel adgang. Et rettighedsstop er ikke et tomt datasæt. Et prepare-resultat reserverer ikke en fremtidig commit.

Ukendt udfald og kendt operations-ID

Hvis hele det første HTTP-svar går tabt, kender klienten normalt ikke operation_id. Den skal først gentage den oprindelige skriveoperation med samme idempotensnøgle og input. Når identiteten er kendt, kan dette endpoint bruges til et snævert kvitteringsopslag.

En registreret konflikt eller domæneafvisning kan også have en kvittering. Læs derfor http_status sammen med result; et eksisterende kvitterings-ID er ikke i sig selv bevis på succes. En status på 201 for en fakturakladde er stadig kun kladdeoprettelse.

En tilbagekaldt grant eller en ny grant giver ikke automatisk læseret til den gamle grants kvitteringer. Bevar den oprindelige kontekst i din egen revisionslog, og brug Hours' supportprocedure ved et uløseligt tilfælde. Del aldrig tokenværdier eller rå kundedata som genvej.

Test din integration

Test korrekt kontekst, manglende scope, forkert miljø og fremmede referencer. Test kvitteringsopslag med en anden app og med en ny grant.

Se rettigheder, fejl og idempotens.