Expertise

Middleware en
API's.

Systemen die oorspronkelijk niet met elkaar wilden praten, wij leggen de verbinding. Schaalbaar, gedocumenteerd en built to last.

Integratie is het fundament, geen bijzaak.

In vrijwel elk bedrijf staat de waardevolle data verspreid over systemen die niet met elkaar praten. Een ERP kent de voorraad, de webshop kent de bestelling, het boekhoudpakket kent de factuur, en het CRM kent de klant. Pas als die vier met elkaar in gesprek gaan, ontstaat er iets wat écht werkt, voor je team én voor je klanten.

Wij bouwen die gesprekslaag. Dat kan een simpele REST-koppeling zijn tussen twee systemen, maar even goed een volledige middleware-laag met een event-bus, message queues en een eigen datamodel. Welke kant het opgaat hangt af van volume, realtime-eisen en hoeveel partijen meeluisteren.

Wat in alle varianten terugkomt: endpoints die idempotent zijn, retry-logica die niet in een oneindige lus kan vastlopen, monitoring die ons waarschuwt vóór je klanten dat doen, en documentatie die matcht met wat de code doet. Integraties gaan stuk, het doel is dat je dat merkt voordat het een incident wordt.

// wat_we_bouwen

Wat wij bieden

Van één-op-één koppeling tot complete middleware-laag.

REST- en GraphQL-API's

Contract-first ontwerp met OpenAPI of SDL, versiebeheer vanaf dag één en SDK's waar nuttig. Clients die we zelf niet schrijven, krijgen autogegenereerde documentatie met voorbeelden.

Webhooks en event-infrastructuur

Inkomende webhooks met signatureverificatie, uitgaande events met retry-beleid en een dead-letter queue voor hardnekkige fouten. Geen verloren berichten, wél een audittrail.

OAuth2 en JWT

Standaard-authenticatie voor externe integraties en eigen clients. Scoped tokens, refresh-flow en rotatie zonder downtime.

Rate limiting en caching

Per-client en per-endpoint limieten, Redis-gebaseerde response-caching en ETags om onnodig verkeer te vermijden. Schaalt tot miljoenen requests per dag.

Observability

Structured logging, request-tracing en dashboards op foutmarge en latency. Als iets langzamer wordt, weten wij het vóór je klant.

OpenAPI-documentatie die klopt

Documentatie wordt uit de code gegenereerd, geen aparte Confluence-pagina die ondertussen verouderd is. Externe partijen en je eigen team kijken naar dezelfde waarheid.

// aanpak

Zo werken we

01

Discovery

We brengen het landschap in kaart: welke systemen, welke data, welke eigenaars. Daaruit rolt een concrete integratie-architectuur met scope per koppeling.

02

Contract-first ontwerp

Voordat er één regel code wordt geschreven, leggen we het API-contract vast in OpenAPI of GraphQL SDL. Frontend en backend bouwen parallel tegen hetzelfde contract.

03

Bouw met tests

Unit-, integratie- en contract-tests draaien in CI. Sandbox-omgevingen van leveranciers worden elke nacht gecheckt, zodat we weten wanneer hún contract verandert.

04

Beheer en doorontwikkeling

Na oplevering blijven we betrokken. Monitoring, version-bumps, nieuwe endpoints, onder Platform Partnership of op afroep.

// stack

Waarmee we werken

Een stack die volwassen is, door ons team gekend tot in de randgevallen.

Backend en runtime

  • Laravel (PHP 8.4) met queued jobs
  • Node.js / TypeScript voor event-workers
  • PostgreSQL en Redis
  • RabbitMQ / Laravel Horizon

Integraties die we kennen

  • Moneybird, Exact, AFAS, Twinfield
  • Shopify, WooCommerce, Magento
  • HubSpot, Pipedrive, Teamleader
  • Stripe, Mollie, Adyen
  • Google Workspace, Microsoft Graph
  • Slack, Teams, n8n

Hosting en observability

  • AWS (ECS, RDS, SQS) en Hetzner
  • GitHub Actions CI/CD
  • Sentry, Grafana, Loki
  • OpenTelemetry tracing
// scenarios

Hoe dit er in de praktijk uitziet

Webshop ↔ ERP: voorraad in realtime

Een groothandel verkocht via WooCommerce, maar de voorraad werd beheerd in een ERP. Oversell tijdens drukke uren was de dagelijkse realiteit. Wij bouwden een middleware-laag die voorraadmutaties uit het ERP ontvangt via webhooks, deze via een message queue naar de webshop doorzet en bij concurrent bestellingen een soft-lock op voorraad toepast. Resultaat: nul oversells in het eerste kwartaal na livegang.

CRM ↔ boekhouding: één klantbeeld

Sales werkte in HubSpot, finance in Exact Online, en elke maand werden contacten en facturen met de hand afgestemd. Wij koppelden beide systemen met bidirectionele sync op contactniveau en eenrichtings-facturen van HubSpot deals naar Exact. Dubbele contacten werden gedetecteerd via fuzzy matching, conflicten kwamen in een review-queue voor de accountmanager. Handmatige afstemming ging van een dag per maand naar nul.

Multi-source dashboard

Een organisatie wilde marketing-, sales- en support-KPI's in één beeld. Data zat in Google Ads, HubSpot, Zendesk en een eigen database. Wij bouwden een headless API die uit zeven bronnen trekt, normaliseert en één GraphQL-endpoint aanbiedt. Een React-dashboard bevraagt dat endpoint met caching per query. Wat eerst een wekelijkse export-sheet was, werd een live dashboard dat met de organisatie meegroeide.

Veelgestelde vragen

Wanneer kies je REST en wanneer GraphQL?
REST is de pragmatische default: bekend, goed gecachet door HTTP-infrastructuur en makkelijk door elke client te consumeren. GraphQL kiezen we als een frontend veel verschillende selecties op dezelfde data nodig heeft, of als we willen voorkomen dat we voor elk scherm een nieuw endpoint bouwen. In veel projecten werken beide naast elkaar: REST voor machine-to-machine integraties, GraphQL voor een productfrontend.
Wat als een leverancier geen API heeft?
Dan bouwen we een adapter. Dat kan gaan van gestructureerde CSV-exports via (S)FTP, scraping van een portaal met een headless browser, tot een e-mail-parser die bijlagen inleest. De kunst zit 'm er in om die fragiele laag zo te isoleren dat de rest van het platform niet merkt waar de data vandaan komt. Als de leverancier later wél een API uitbrengt, wisselen we alleen de adapter.
Hoe voorkomen jullie dat koppelingen breken bij een update?
Drie lagen. Eén: contract-tests, geautomatiseerde checks tegen een sandbox van de leverancier die 's nachts draaien en ons waarschuwen voordat klanten het merken. Twee: versiebeheer op onze eigen API's zodat clients niet breken als wij veranderen. Drie: monitoring op foutmarges en responstijden, zodat afwijkingen zichtbaar worden voordat ze klantenproblemen worden.
Kunnen jullie een bestaande API ook documenteren?
Ja. We leveren OpenAPI-specificaties (Swagger) met voorbeelden per endpoint, zowel voor nieuwe API's die wij bouwen als voor bestaande endpoints die historisch niet gedocumenteerd waren. Dat helpt niet alleen externe integrators, maar ook toekomstige ontwikkelaars in je eigen team.
Hoe gaan jullie om met rate limits van externe API's?
Met queueing. Verzoeken richting externe systemen lopen via een jobqueue met een rate-limiter per leverancier. Zo overschrijden we geen limieten, krijgen tijdelijke uitval een nette retry met exponentieel wachten, en blijft onze eigen applicatie responsief. Herhaalde fouten landen op een dead-letter queue voor inspectie.
Hoe lang duurt een koppeling gemiddeld?
Een eenvoudige REST-koppeling met OAuth2 en webhook-ontvangst is meestal in enkele weken klaar, inclusief tests en monitoring. Maatwerk-integraties met event-driven architectuur of complexe data-mapping lopen op tot enkele maanden. We geven altijd eerst een concrete scope per koppeling af na een korte Discovery, zo weet je vooraf waar je aan toe bent.
+ + + +

// volgende_stap.execute()

Een koppeling in gedachten?

Vertel welke systemen met elkaar moeten praten, wij geven een concrete architectuur en fasering terug.