Adgangsmodel
Partner-API'et bruger afgrænsede, uigennemsigtige apptokens. Produktionskald går til /api/partner/v1, og sandboxkald går til /api/partner/sandbox/v1 på den installation, som appen er konfigureret til. Basisadressen for appen vises i App Console; eksemplerne i dokumentationen bruger miljøvariablerne HOURS_ORIGIN og HOURS_BASE.
Partner-API'ets operationer
| Metode og relativ sti | Krævet scope | Sideeffekt |
|---|---|---|
GET /configuration | configuration:read | Henter kun de kontoreferencer, grantet tillader. |
POST /journal/prepare | journal:prepare | Kontrollerer input og referencer; bogfører ikke. |
POST /journal | journal:post | Bogfører gennem Hours' regnskabskerne. |
GET /journal | journal:read | Læser organisationens bogførte posteringer på tildelte konti. |
POST /products | products:write | Opretter et afgrænset produkt. |
GET /products | products:read | Læser organisationens produkter. |
POST /invoices | invoices:write | Opretter en fakturakladde. |
GET /invoices | invoices:read | Læser organisationens salgsfakturaer. |
GET /operations/{id} | operations:read | Henter en minimal kvittering for appens egen operation. |
Skriveoperationerne med vedvarende effekt kræver Idempotency-Key. Klargøring gør ikke. Alle skrivepayloads afviser ukendte felter; der er ikke et bagvedliggende "send hvad som helst videre"-objekt. Valutaen i partnerprofilen er DKK, også hvor Hours' regnskabskerne kan repræsentere mere.
Hvad læseoperationerne faktisk returnerer
Læseoperationerne læser organisationens eksisterende regnskabsdata, ikke kun det appen selv har oprettet. GET /journal viser organisationens bogførte posteringer, kun linjer på de konti kunden har tildelt. GET /products og GET /invoices viser organisationens produkter og salgsfakturaer. Ingen svar indeholder bank-, betalings-, afsender-bankkonto- eller Stripe-felter.
Adgang kræver en godkendt apprevision, en kundegrant og de relevante scopes. Grantet gives af organisationsejeren med tofaktor, for valgte konti og højst 90 dage. Der er intet separat tjek af et produktmodul.
Journallistens parametre er limit (1-100, standard 50), after, from og to (YYYY-MM-DD). Cursoren after er posteringsnummeret som en streng af cifre. Produkt- og fakturalisten bruger en UUID som after. Beløb er hele øre, højst 99 999 999 999 999 pr. linje, og hver journallinje har præcis én af debit_minor og credit_minor over nul. Integrationer må ikke omgå grænserne med direkte Supabase-adgang.
Input, svar og HTTP-adfærd
Brug JSON med Content-Type: application/json til domæneskrivninger. Bodygrænsen er 256 KiB. OAuth-tokenkald bruger derimod formularformat og er beskrevet i autentifikationsguiden. Brug ikke multipart-upload til domæneruterne; filupload er ikke en partneroperation.
Succesfulde svar og fejl har Cache-Control: no-store. Et request-ID gør det muligt at sammenholde klientens fejl med driftens logs uden at sende tokens eller hele payloads til support. Lister anvender den afgrænsede limit/after-model (journallisten desuden from og to); de accepterer ikke frie SQL-lignende filtre, expand eller kundesendte organisations-ID'er.
Områder, der ikke er åbnet
Bankdata og betalingsudførelse er eksplicit udelukket. Bilagsfiler, kontrakteksport, godkendelsesbeslutninger, medarbejderdata, løn, generel rapporteksport og model-inference er heller ikke partneroperationer. Produktvejledningerne forklarer, hvordan disse emner påvirker en integration, men de opfinder ikke manglende endpoints. Se versionering for, hvordan kontrakten ændres.
Før du starter en produktionsintegration
Gennemfør første kald, test idempotens, og implementér de relevante fejlforløb. Afstem derefter apprevision, kundens grant og det aktiverede miljø. En testtoken eller et sandboxresultat kan aldrig bruges som bevis for produktionsadgang.