A proof of concept built during my internship at H.Essers — a logistics company based in Genk, Belgium. The project automates the manual process of forwarding shipment emails from Outlook into an internal dispatch system, using an Outlook Add-in paired with an event-driven backend.
H.Essers is an international logistics and transport company headquartered in Genk, Belgium. With operations across Europe and beyond, they handle complex supply chains for sectors including healthcare, chemicals and general cargo. The company employs thousands of logistics coordinators who manage daily shipment operations — many of which still rely heavily on email workflows.
Logistics coordinators at H.Essers received shipment data by email and had to manually re-enter it into internal dispatch systems. This process was slow, error-prone and impossible to audit at scale.
I designed and built an Outlook Add-in that lets users submit selected emails and attachments directly to a downstream system. Behind an API gateway (Gravitee), a custom Ingest API retrieves the full email via Microsoft Graph and publishes a structured event to a Kafka topic for async downstream processing.
Coordinators can forward an email directly from Outlook without leaving the app. The backend processes it asynchronously, stores the content, and triggers the downstream workflow — fully logged and traceable end to end.
Built with Office.js, the add-in renders a task pane inside Outlook. When a user selects an email and clicks submit, the add-in reads the email metadata and passes it to the API gateway. Authentication is handled via OAuth2 with Microsoft identity platform.
All traffic flows through Gravitee as the API gateway. It handles routing, rate limiting and security policies. The gateway forwards validated requests to the Ingest API running behind it.
The core backend service. It receives the submission from the gateway, fetches the full email and attachments via the Microsoft Graph API using an OBO (On-Behalf-Of) OAuth2 flow, then publishes a structured event to a Kafka topic. Custom handling includes deduplication logic, retry mechanisms and a Dead Letter Queue for failed events.
Events are published to a Kafka topic for async downstream processing. A Kafka consumer service processes each event, with deduplication to prevent duplicate submissions and full audit logging for traceability.
A full CI/CD pipeline was set up for GitHub Actions — including build, test and deployment stages. The pipeline is ready to deploy the full system when the organisation decides to move from proof of concept to production.
Technical realisation document describing the implementation, architecture decisions and deliverables of the internship project.
Personal reflection on the internship experience — what went well, what I would do differently, and how the project shaped my growth as a developer.
The initial project plan submitted at the start of the internship — scope, objectives, timeline and technical approach.