e-conomic

Integration til e-conomic: hvad kræver det?

Senest opdateret 10 oktober 2026

Hvis du er ved at gå i gang, er der to ting, der oftest vælter et estimat: du bygger formentlig på den API, der er sat i frys — og din kundes abonnement har måske slet ikke API-adgang. Begge kan afklares i dag.

Der er tre API’er, og den rigtige er ikke den, folk finder først

Det praktiske svar: begynd på OpenAPI, og fald kun tilbage til REST for de huller, der er. De to bruger samme autentifikation og kan bruges side om side, så det er ikke et enten-eller.

REST er i øvrigt ikke forladt — endepunktet svarede med en build dateret 9. oktober 2026, dagen før jeg skrev dette. Feature freeze betyder frys, ikke nedlukning, og der er ikke offentliggjort nogen slutdato for REST.

Autentifikationen, præcist

Det er ikke OAuth. Det er to tokens, der tilsammen udgør nøglen: et hemmeligt app-token, som er dit, og et aftaletoken pr. kunde, som kunden giver dig. Kunden afgiver altså ikke sit kodeord.

• App-tokenet får du ved at oprette en gratis udvikleraftale og en app. Det vises én gang — e-conomic skriver, at det ikke vises igen, men at man altid kan generere et nyt ved at nulstille.
• Aftaletokenet får du ved at sende kunden appens installationslink. Kunden skal være logget ind på en aftale med regnskabsdata, og administratorer skal først trykke “Administrer”.
• Du kan få tokenet tilbage automatisk på to dokumenterede måder: via PartnerAPI’et, eller ved at sætte et redirect-link, hvor tokenet kommer med som en URL-parameter.
• Installationslinket tager en locale-parameter, der accepterer da-DK.

Og så de headere, det hele hænger på:

Til en hurtig test kan du kalde /self eller /customers. Der findes også demoadgang med demo som begge tokens, men den er kun læsning.

Én ting er ikke dokumenteret, og det er værd at vide på forhånd: tokenets levetid og hvordan en kunde trækker adgangen tilbage. Der står ikke andet end muligheden for at nulstille app-tokenet. Planlæg for, at adgangen kan forsvinde uden varsel.

Blokeringen, ingen advarer om: kundens abonnement

Priserne er fra-priser ved det laveste posteringsniveau og stiger med antallet af posteringer. Men pointen er ikke prisen — det er, at et projekt kan stå stille på en opgradering på 50 kroner om måneden, som kunden ikke vidste var nødvendig. Spørg om pakken, inden du giver en pris.

Grænser for antal kald — to svar, der ikke er ens

Her skal man kende begge, fordi det ældste tal er det, der citeres overalt:

• e-conomics krav til app-partnere: “Fair use is defined as 50.000 API calls per 24 hour period per agreement”, og e-conomic kan uden varsel begrænse en integration, der belaster platformen.
• API-vilkårene, opdateret 12. juni 2026, siger i stedet, at brugen reguleres via en token bucket-model, hvor hvert endepunkt koster et antal tokens af aftalens pulje — og at e-conomic kan indføre trindelte puljer uden forudgående varsel.

De to kan godt eksistere side om side, men vilkårene er nyere. Og: der findes ingen offentliggjort grænse pr. minut, ingen oplyst samtidighedsgrænse og ingen sidestørrelsesgrænse, jeg har kunnet finde. Priserne pr. endepunkt ligger i den tekniske guide, som kræver, at man er inde i dokumentationsværktøjet.

Læs vilkårene, inden du designer

Det her er afsnittet, jeg selv ville have læst først, og som ingen anden side om emnet nævner. Fra API-vilkårene, opdateret 12. juni 2026:

Hver af dem er til at leve med. Men tre af dem — forbuddet mod en parallel database, forbuddet mod permanent cache og 12-månedersgrænsen for en hovedversion — er arkitekturbeslutninger, og de er dyre at opdage, når der er bygget.

At komme i app-markedet

Fem offentliggjorte krav: appen skal bruge tokenmodellen, fair use skal overholdes, der skal være e-mailsupport med personlige svar inden for 24 timer — ikke autosvar — der skal være en dedikeret e-conomic-side på jeres eget website med link tilbage, og I skal fortælle e-conomic, hvis onboardingforløbet ændres.

Processen er en live test sammen med e-conomic via skærmdeling, plus en forberedt præsentation, der skal dække virksomheden, produktet, hovedfunktionerne, forretningsmodellen, onboardingforløbet, kundeværdien og hvordan data kan ind og ud — både i jeres app og i e-conomic. Listningen på websitet og i markedspladsen inde i produktet er to separate indsendelser.

Og det, der ikke er offentliggjort: ingen tidsramme for nogen af trinnene, intet gebyr, ingen omsætningsdeling — og intet krav om sikkerhedsrevision eller dokumentation i de offentliggjorte krav. Jeg kan ikke sige, hvor lang tid godkendelsen tager, fordi e-conomic ikke oplyser det.

Den danske regulering, som e-conomic ikke nævner

Jeg gennemgik API-vilkårene for omtale af bogføringsloven, digitale bogføringssystemer, revisionsspor, Nemhandel, OIOUBL og Peppol. Ingen af dem nævnes. Vilkårene siger intet om, hvad en integrator ikke må bryde.

Det betyder ikke, at kravene ikke findes — det betyder, at byrden ligger hos dig og kunden. Bygger du på et registreret digitalt bogføringssystem, gælder Erhvervsstyrelsens krav uafhængigt af API-vilkårene, og e-fakturadelen er i bevægelse: OIOUBL 3.0 blev aflyst i januar 2026 til fordel for en dansk Peppol BIS 4-profil med indfasning i 2028-29. Det har jeg gennemgået separat.

Den eneste tilgrænsende udmelding, jeg fandt fra e-conomic, er fra deres blog i marts 2023 og er markedsføring, ikke udviklermateriale: at kunden kan blive ansvarlig for it-sikkerheden, hvis de vælger at integrere en ekstern tredjepartsapplikation. Det er værd at have aftalt med kunden, hvem der bærer hvad.

Bygge selv eller gå gennem mellemlag?

Der findes samlede regnskabs-API’er, der dokumenterer e-conomic. Nango gør det — men beskriver det som værktøj uden færdige synkroniseringer eller handlinger endnu, og siden har ingen dato, så jeg kan ikke sige hvor aktuel den er. Jeg nævner den, fordi den findes, ikke som en anbefaling. Og bemærk, at de gentager tallet på 50.000 kald i døgnet.

Og SOAP, for fuldstændighedens skyld

Her modsiger e-conomics egne sider hinanden. Nedlukningssiden siger, at SOAP “will finally be deprecated (closed) in 2023”. Den aktuelle API-køreplan har stadig nedlukningen af SOAP som et mellemfristet punkt uden dato, og endepunktet er stadig publiceret.

Så: byg ikke nyt på SOAP, men regn heller ikke med, at et eksisterende SOAP-integration er død i morgen. Og hvis du overtager en, så find ud af, hvilke OpenAPI-endepunkter der dækker den — e-conomic har en tjeneste, der matcher dem.

Kilder. Valget mellem API’erne, autentifikationen og kravene til app-partnere: e-conomics egne udviklersider på e-conomic.com/developer — citaterne er ordrette fra siderne om valg af API, om at forbinde en app og om krav til app-partnere. Siderne oplyser ingen udgivelsesdato. Grænser og vilkår: e-conomics API Terms of Service, der selv angiver “Updated the 12/06/2026” — token bucket-modellen, forbuddene mod AI-træning, parallel database og permanent cache, 12-månedersgrænsen, ansvarsbegrænsningen på 0 kr. og sanktionen på 100.000 kr. er gengivet herfra, de citerede passager ordret. Tallet på 50.000 kald pr. 24 timer står på siden om krav til app-partnere og er altså et ældre dokument. Priser: e-conomic.dk/priser, uden dato på siden, ved laveste posteringsniveau og ekskl. moms. Angivet som fra-priser, fordi prisen stiger med antal posteringer. SOAP: e-conomics egen nedlukningsside og den aktuelle API-køreplan, som ikke stemmer overens. At vilkårene intet nævner om bogføringsloven, Nemhandel, OIOUBL eller Peppol er min egen gennemgang af dokumentet, oktober 2026. Jeg har ikke kunnet læse OpenAPI-dokumentationens endepunkter og tokenpriser, fordi dokumentationsværktøjet kræver JavaScript — så der er ingen endepunktsliste på denne side. Alt hentet 10. oktober 2026. Vilkårene blev ændret i juni 2026 og kan ændres igen.