Ikke et skjult premium-scope
Der findes ikke et bank:*-scope i Partner-API'ets tilladelsesliste. En udvikler kan ikke ansøge om det ved at ændre JSON, og en reviewer kan ikke tildele en ukendt tilladelse. Ukendte routes og operationer bliver afvist frem for videresendt til en intern providerintegration.
Bankforbuddet er en produktmæssig grænse for den eksterne kontrakt. Dokumentationen hævder ikke, at en intern Hours-godkendelse kan ophæve Stripe-, Enable Banking- eller andre leverandørvilkår. De konkrete aftaler og behandlingsroller skal vurderes separat, hvis dataflowet ændres.
Direkte og indirekte udlevering
En intern postering, faktura eller rapport kan have relationer til bankdata, selv om adressen ikke indeholder ordet “bank”. Et generisk dokumentopslag kan eksempelvis returnere rå normaliseret input, en providerreference eller en relation til afstemningen. Derfor er et blokeret bankendpoint ikke nok.
Partner-API'et bruger eksplicitte outputprojektioner uden bank-, betalings-, afsender-bankkonto- eller Stripe-felter. Det publicerer ikke Hours' samlede dokumentbestand, vilkårlige rapporter eller generelle eksportfunktioner. Webhookpayloaden indeholder kun en minimal operationshændelse, ikke en beriget kopi af regnskabsobjektet.
Bogføring er ikke open banking
En kunde kan give appen mandat til at indsende en konkret forretningspostering. Det betyder ikke, at appen må hente de banktransaktioner, som kunden senere afstemmer posteringen mod. Et leverandørgældskontonummer i en kontoplan er heller ikke en banksaldo.
Partnerpayloaden accepterer ikke bank_link, providertransaktions-ID, betalingsudførelse eller en fri intern kilde. Serveren bestemmer den tekniske oprindelse. Det forhindrer ikke, at en integrationsudgiver kan have et forkert formål; formålet og det faktiske dataflow vurderes stadig ved review.
Proveniens skal bevares
At omdøbe en banktransaktion til “manuel postering” ændrer ikke, hvor oplysningerne kom fra. Bankproveniensen i Hours er en intern kontrol for miljø og regnskab, men den er ikke en universel feltbaseret eksportpolitik for alle dataflader.
Derfor er Partner-API'ets læseadgang bevidst smallere end generel læsning af alle ikke-bank-navngivne tabeller: den omfatter kun bogførte posteringer på tildelte konti, produkter og salgsfakturaer. En udvidelse kræver en konkret kortlægning af dataoprindelse, tilladte felter, relationer, fritekst og afledte oplysninger. Ukendt herkomst klassificeres ikke stiltiende som fri at dele.
Dokumenter og AI-klienter
En PDF, et billede eller en kontrakt kan indeholde kontooplysninger eller transaktionsdetaljer. Generisk filupload/download og automatisk dokumentudlevering er derfor ikke åbnet i Partner-API'et. En fremtidig dokumentkontrakt skal have en selvstændig model for indhold og adgang.
Hours MCP læser kun offentlig dokumentation. Det kan ikke bede en intern agent om at hente kundens bankdata og returnere dem som et sprogligt svar. Et tool-output er også en dataudlevering; formatet ændrer ikke adgangskravet.
Hvad reviewere og test bør kontrollere
Kontrollér alle outputs, ikke kun navigationens synlige punkter: succes, fejl, dubletter, kvitteringer, lister, webhooks, logs og eventuelle eksportfunktioner. Test også direkte database- og storageadgang med de credentials, partneren faktisk modtager.
Partneren får opaque tokens, som ikke er Supabase-databasecredentials. Det skal fortsat kunne verificeres på den samlede installation, at ingen alternativ rute fortolker dem som en bred adgang eller udleverer data uden for den gældende policy.