API-integrationsspecifikation
Integration: Webshopordrer til regnskab
Version: 1.0
Skrevet af: Hamza Idrissi
Dato: 5. april 2029
1. Formål
Send hver betalt webshopordre til regnskabssystemet som en salgsfaktura, så økonomi ikke skal indtaste den igen.
2. Systemer
- Sender data: Webshop (API v2)
- Modtager data: Regnskabssystem (REST API)
3. Dataflow
1. En kunde betaler for en ordre.
2. Webshoppen sender en webhook til integrationstjenesten.
3. Tjenesten omdanner ordren til en faktura og kalder regnskabs-API'en.
4. Regnskabssystemet returnerer et fakturanummer, som tjenesten gemmer på ordren.
4. Endpoints og meddelelser
| Metode og sti | Hvad den gør | Hovedfelter | Hvad den returnerer |
|---|---|---|---|
| POST /invoices | Opret en faktura | Body: kunde, linjer, moms, total | Returnerer: faktura-id og -nummer |
| GET /customers?email= | Find en kunde | Returnerer: kunde-id eller tom | |
| POST /customers | Opret en kunde | Body: navn, e-mail, adresse |
5. Feltmapping
order.total_paid → invoice.total
order.billing_email → customer.email
order.items[].sku → line.product_code
6. Autentificering og sikkerhed
OAuth 2.0 client credentials. Tokens varer en time. Hemmeligheder opbevares i vaulten, aldrig i kode. Alle kald bruger HTTPS. Webhooks signeres, og signaturen kontrolleres.
Personoplysninger sendes kun, når det er nødvendigt, skrives ikke i logfiler og er omfattet af begge systemers privatlivsvilkår.
7. Fejl og genforsøg
Prøv igen ved 429 og 5xx op til 5 gange med stigende forsinkelser. Prøv ikke igen ved 4xx-fejl; log dem, og giv økonomi besked. Hver faktura har en unik nøgle, så et genforsøg ikke kan oprette en dublet.
8. Grænser og mængder
Regnskabs-API'en tillader 60 kald i minuttet. Der forventes 400 ordrer om dagen, op til 2.000 på udsalgsdage.
9. Test
Brug regnskabssystemets testmiljø. Test en normal ordre, en ordre med rabat, en refundering, en kunde, der allerede findes, og et API-nedbrud.
10. Ejere og support
Ejer: E-handelsteamet. Support: Hamza Idrissi. Eskalering: regnskabsleverandørens supportafdeling.
11. Ændringer og versionering
Hver part giver 30 dages varsel om en brydende ændring.