Felter og betydning
| Felt | Grænse | Hvad feltet bruges til |
|---|---|---|
name | 1–80 tegn | Genkendeligt appnavn i konsol, review og kundeautorisation |
publisher | 1–160 tegn | Den ansvarlige udgiver, ikke navnet på en slutkunde |
description | 40–4.000 tegn | Konkret formål, handlinger og nødvendige data |
homepage | Præcis offentlig HTTPS-URL | Udgiverens eller integrationens informationsside |
privacy_url | Præcis offentlig HTTPS-URL | Beskrivelse af appens egen databehandling |
support_url | Præcis offentlig HTTPS-URL | Kundens og Hours’ mulighed for at få hjælp |
redirect_uris | 1–10 forskellige adresser | Tilladte callbacks efter kundeautorisation |
client_type | public eller confidential | Om klienten kan beskytte en klienthemmelighed. Confidential bruger client_secret_post; public bruger none med PKCE S256 |
requested_scopes | 1–9 kendte, unikke scopes | Appens ansøgte maksimum; ikke tildelte rettigheder |
webhook_url | Valgfri HTTPS-URL | Modtager af minimale operationshændelser |
logo_data_url | Valgfri PNG/WebP | Et lille appmærke, højst 64 KiB og 1.024 × 1.024 pixels |
Konsollen trimmer tekst og afviser kontroltegn. Den accepterer ikke vilkårlige ekstra profilfelter som skjulte adgangsparametre. UI-validering gør formularen lettere at bruge, men serverens samme kontrakt afgør, hvad der kan registreres.
Beskriv et formål, som kan vurderes
En brugbar beskrivelse angiver datakilde, udløsende hændelse, handling i Hours og forventet resultat. Eksempel: “Når en ordre er afsluttet i vores ordresystem, opretter appen en fakturakladde med kundens navn og de afsluttede ordrelinjer. Fakturaen udstedes og sendes efter kundens gennemgang i Hours.”
Den beskrivelse begrunder invoices:write; den begrunder ikke automatisk adgang til tidligere fakturaer, banktransaktioner eller alle organisationer. Angiv særskilt, hvorfor en læserettighed er nødvendig. Hvis formålet kræver data, som partnerkontrakten ikke udstiller, skal produktbehovet vurderes frem for at bruge en intern API-rute uden om konsollen.
Udgiverfeltet er ikke en automatisk virksomhedsverifikation. Hours kontrollerer ikke et CVR-register, domæneejerskab eller en underskrevet partneraftale. Revieweren skal knytte sådant bevis til vurderingen, når det er nødvendigt. Formularens fuldstændighed er ikke det samme som bevisets fuldstændighed.
Redirectadresser skal være præcise
Registrér kun callbacks, som integrationen faktisk kontrollerer. Brug en særskilt callbackpath og undgå generelle redirector-endpoints, der selv tager en fri next-adresse. Ellers kan en korrekt registreret callback blive en indirekte åben redirect.
Adressevalideringen afviser wildcard, userinfo, fragment, private værtsnavne og ikke-kanoniske repræsentationer. https://partner.example/ og https://partner.example/callback er forskellige adresser. En testadresse med HTTP-loopback kan registreres i kladden, men produktionsreview kræver HTTPS på samtlige registrerede redirects.
OAuth-implementationen accepterer ikke custom URI schemes eller en dynamisk portundtagelse for public native apps. Vælg ikke public klient alene for at undgå at drive en backend; klientens callback- og tokenflow skal passe til den faktisk understøttede kontrakt.
Logo og øvrige URL’er er ubetroet input
Logoet uploades som begrænset billedindhold; serveren henter ikke en vilkårlig logo-URL. PNG/WebP-format, signatur, dimensioner og filstørrelse kontrolleres. Billedet skal stadig behandles som ubetroet indhold i browseren. SVG, HTML og scripts er ikke tilladt som appbranding.
Hjemmeside, privatlivspolitik og supportlink skal beskrive appen og udgiveren. En syntaktisk gyldig URL kan stadig være irrelevant, utilgængelig eller kontrolleret af en anden part. Review skal derfor omfatte indhold og ejerskab; regex-validering kan ikke afgøre disse forhold.
Revisioner og samtidig redigering
Ved oprettelse starter appen på revision 1. En ændring sendes med expected_revision. Serveren låser den relevante arbejdsrums- og appstate og afviser, hvis den forventede revision ikke længere er aktuel. Hent den nye version, og afklar forskellen i stedet for at overskrive en kollegas arbejde.
En gemt profilændring opretter en ny, uforanderlig revisionspost. Appens gamle grants og tokens tilbagekaldes, og appen vender tilbage til kladdestatus. Modellen er streng, men tydelig: ingen gammel kundeaccept gælder stiltiende for et nyt adgangsgrundlag.
Konsollen advarer om ikke-gemte ændringer ved appskift og lukning. Advarslen er UX, ikke adgangskontrol. En afbrudt browser eller et tabt svar kan stadig kræve genindlæsning af serverens aktuelle revision. Brug revisionsnummeret som sandhed.
Klar til næste trin
Kontrollér profilens faktiske indhold, valgte scopes og testadresser, før du åbner sandbox eller sender til review. Gem ikke nøgler, tokens, kundebilag eller personnumre i formålsfeltet. Appens interne hemmeligheder hører i et secret manager-system, ikke i en offentlig beskrivelse.
Fortsæt med sandbox for test og appreview for produktionsforløbet. Appregistrering giver hverken adgang til kundedata eller ret til at kalde skjulte moduler.