Indsendelse, bogføring og læsning er forskellige rettigheder
products:write tillader produktoprettelse inden for den konkrete grant. Det giver ikke products:read. invoices:write tillader oprettelse af en fakturakladde, ikke endelig bogføring, betaling eller læsning af eksisterende fakturaer. Fakturakladden er ikke udstedt.
journal:prepare og journal:post er ligeledes adskilt. Det sidste kræver et særskilt mandat. Der findes ikke en generel “skriv alt”-tilladelse, og der findes ikke en skjult standardlæserettighed, som følger med et client secret.
Nødvendige referencer uden bred datalæsning
En skriveoperation kan have brug for kundens udvalgte konto-ID’er. Kunden vælger dette konfigurationssæt ved autorisation. configuration:read returnerer netop det begrænsede udsnit, ikke kundens posteringer, bankkonti eller samlede kontoplan.
Det er en konkret, snæver læseret og vises som sådan. Den må ikke markedsføres som “ingen dataadgang overhovedet”, hvis den faktisk viser kontonavne og referencer. Forskellen er mellem den nødvendige konfiguration og en generel udlevering af forretningsdata.
Kvittering er ikke fuld ressource
En skrivekvittering fortæller appen, om dens egen operation lykkedes, og hvilken minimal identitet resultatet fik. Den henter ikke en intern række med alle kolonner og kalder det “metadata”.
Dette er særlig vigtigt ved deduplikering. Partner-API'et returnerer ikke en eksisterende fuld række ved et CVR-hit. En app, som selv indsender et CVR-nummer, har ikke dermed ret til virksomhedens øvrige noter, bankoplysninger eller tidligere relationer.
Fejl må heller ikke blive et læse-API
Fejlbeskeder afslører ikke en fremmed organisations navn, en skjult modparts fulde identitet eller indholdet af en bankrelateret række. Du får en stabil afvisning og en brugbar forklaring, ikke de oplysninger, som kontrollen netop nægtede appen.
Det samme gælder konflikter. En unikhedskonflikt kan fortælle, at operationen ikke kan gennemføres i den aktuelle kontekst. Den afslører ikke, hvilken anden organisation der ejer den konflikterende række.
Læsescopes er en særskilt beslutning
journal:read, products:read og invoices:read læser organisationens eksisterende regnskabsdata: bogførte posteringer på de konti, kunden har tildelt, produkter og salgsfakturaer, uden bank- og betalingsfelter. Kunden skal give dem udtrykkeligt ved autorisationen, og de følger ikke med et skrivescope.
En integration, der kun skal sende data ind, bør derfor ikke bede om dem. Se pagination for konsekvenserne for synkronisering.
Bankforbuddet gælder også skriveflowet
Gatewayen accepterer ikke bankproviderpayloads eller direkte betalingsinitiering. En partner må ikke sende et source: manual-stempel for at gøre en banktransaktion til en almindelig postering. Den konkrete forretningspostering skal være autoriseret og regnskabsmæssigt begrundet; bankdataudtræk er fortsat lukket.
Partner-API'et bruger et begrænset input- og outputskema. Det er ikke en universel klassifikationsmotor, som kan bevise, at vilkårlig fritekst aldrig omtaler bankoplysninger. Upload af rå filer og generiske objekter er ikke udgivet.
Hvad testen skal vise
Test at en app med kun skriveret ikke kan bruge listerne og får insufficient_scope. Test at et dubletkald kun returnerer den minimale, egen kvittering. Test et andet app-ID, en anden organisations reference, et udløbet grant og et forsøg på at smugle beskyttede felter ind.
Test også efterfølgende leveringer: en webhook må ikke beriges med den fulde interne række, og et kvitteringsopslag skal genkontrollere aktuel adgang. Ellers er write-only kun en etiket på den første knap, ikke en håndhævet egenskab ved integrationen.