HoursUdviklere
OverblikIkke frigivet

Velkommen til Hours

Denne dokumentation er til udvikleren, der skal bygge en integration, den kunde, der skal godkende dens adgang, og den driftsansvarlige, der skal kunne forklare, hvad der skete, når et kald fejler.

Vælg den rigtige indgang

Arbejder du i Hours som almindelig bruger, er produktvejledningerne relevante. Udvikler du et eksternt produkt, skal du begynde med App Console og partnerkontrakten. Eksempler på Hours' interne operationer må ikke kopieres ind i en partnerintegration og forsynes med et tilfældigt Bearer-token.

Den eksisterende kundesession og en eksternt autoriseret app repræsenterer forskellige aktører. En kundesession kan have adgang til flere interne arbejdsprocesser. Appen får kun det udsnit, som dens review, kundens grant og den konkrete operation tillader. Login til konsollen er ikke login som en af kundens medarbejdere.

De vigtigste begreber

Et arbejdsrum er udgiverens fælles plads til apps og udviklerteamet. En app er den identificerede integration. En revision er en bestemt udgave af appens profil, tekniske adresser og ønskede scopes. Et review er Hours' beslutning om denne revision. En grant er en konkret kundes autorisation af revisionen til én organisation, valgte konti og en begrænset periode på højst 90 dage; organisationsejeren giver den med tofaktor.

Et credential er et teknisk bevis på appens identitet; det er ikke i sig selv en kundetilladelse. Et access-token er knyttet til en konkret autorisation. Et sandboxtoken er derimod knyttet til en app og en generation i testmiljøet. De to tokenklasser må ikke byttes rundt.

En operation er én gatewayhandling med en minimal, sporbar kvittering. En operation kan være gennemført, selv om klienten ikke modtog HTTP-svaret. Derfor findes både idempotens og kvitteringsopslag. Det er ikke nok at vise en grøn toast i klienten.

Et normalt udviklingsforløb

Opret først appen med en beskrivelse, som en kunde kan forstå. Angiv ikke blot "regnskabsintegration"; forklar eksempelvis, at appen indsender en dagsomsætning fra et bestemt system og bogfører på kundens valgte konti. Den beskrivelse gør det muligt at vælge smalle scopes og vurdere risikoen ved automatisering.

Test derefter i sandbox. Begynd med en gyldig postering, og test også en forkert organisation, et produktions-token på sandboxruten, en ukendt kontoreference og en gentaget idempotensnøgle med ændret input. Et vellykket enkeltkald er ikke et færdigt integrationsforløb.

Indsend først appen til review, når flowet, fejlbehandlingen og databehandlingen kan forklares. I produktion skal organisationsejeren selv vælge organisation, konti og adgang. Ved endelig bogføring kræves et særskilt bogføringsmandat; det følger ikke automatisk med tilladelsen til at forberede input.

Hvad dokumentationen ikke lover

Dokumentationen er ikke et tilbud om bestemte priser, en service-level-aftale eller en erklæring om certificering. Der er heller ikke et offentligt model-inference-API, bare fordi Hours anvender AI i produktet. Sider om Amber og produktområder beskriver relevante grænser og arbejdsgange uden at opfinde nye endpoints.

Klienteksemplerne anvender miljøvariabler for basisadressen. Basisadressen for din app vises i App Console.

Sådan læser du en referenceside

Kontrollér først, om siden handler om partner-API'et eller om en intern operation i Hours. Læs derefter forudsætninger, scope, input, svar og fejl. Vær især opmærksom på sideeffekter: "opret kladde" og "bogfør" er ikke synonymer.

Brug højremenuen til at gå direkte til felter eller fejlsøgning. "Kopiér side" og "Vis som Markdown" indeholder den offentlige dokumentation, ikke appens secrets eller kundens data. Datamodeller, første kald og Console-guiden er den sammenhængende introduktion.

Velkommen til Hours · Hours Udviklere