Building B2B Integration APIs: Connecting Value Ed to Deviare's LMS

Some of the most valuable technical work happens where nobody sees it.

No flashy interfaces. No consumer apps. No screenshots to show off. Just code that makes two systems talk to each other — quietly enabling partnerships that wouldn't otherwise exist.

This is the story of building the integration layer between Value Ed and Deviare. And what it taught me about working across organisations, gathering requirements properly, and why communication is as much a technical skill as writing clean code.

Two Organisations, One Opportunity

Value Ed and Deviare were a natural fit.

Value Ed runs programs that prepare graduates for their first jobs — the soft skills, professional development, and work-readiness training that universities often skip over. The stuff that turns nervous graduates into confident employees.

Deviare hires numerous graduates every year. They needed their new people to be job-ready. Value Ed's sessions could help get them there.

The partnership made sense. The handshake was easy.

The technical challenge was making it actually work.

The Problem Beneath the Partnership

Deviare had their own Learning Management System where graduates accessed training content. They wanted Value Ed sessions to appear directly in that LMS — not as a separate platform their employees had to navigate to, remember passwords for, and inevitably forget existed.

But it wasn't as simple as *give them access to everything*.

Value Ed needed to:

• **Expose only select sessions** — not their entire catalogue
• **Restrict access to specific Deviare members** — not open to the public
• **Track attendance** — create a clear record of which graduates showed up to which sessions

In other words, we needed a controlled, secure, auditable integration between two independent platforms.

That meant building APIs.

The Tools I Reached For

I built the integration layer using:

• **Python with FastAPI** — Fast to develop, excellent for API work, and it auto-generates documentation that saves hours of back-and-forth with external teams
• **API key authentication** — Simple, secure, appropriate for B2B integrations
• **Vercel for hosting** — Reliable, scalable, painless deployment
• **Zoom API integration** — For pulling session links and attendance data
• **Watchdog for monitoring** — Keeping an eye on system health so problems surface before they become emergencies

FastAPI was the right call for this. It's built for exactly this kind of work. The automatic Swagger documentation it generates made sharing specifications with Deviare's team almost effortless.

Seven Endpoints, Seven Needs

I designed a suite of seven endpoints, each born from specific requirements that emerged during our planning conversations:

Data flowing through these pipes included session details, Zoom meeting links, host information from Value Ed's systems, and attendance records captured live.

Seven endpoints. Each one a small bridge between two worlds.

The Tricky Part Wasn't What You'd Expect

The hardest challenge wasn't security or performance.

It was data transformation.

Value Ed stored session information one way. Zoom's API returned data in a completely different structure. Deviare's LMS expected yet another format.

I became the translator.

Pull host names and session breakdowns from Value Ed's existing systems. Combine them with live session details and attendance records from Zoom. Package everything in exactly the format Deviare's LMS could consume.

It looks simple on paper. In practice, it meant careful attention to edge cases, null values, timezone handling, and the kind of data consistency issues that only show up when real information flows through your carefully constructed pipes.

Transforming data between systems isn't glamorous. But when it works, two organisations that couldn't talk before suddenly can.

The Lesson I'm Most Grateful For

This project carved something deep into my approach: **understand the full scope before writing code**.

We spent significant time on requirements sourcing and data modelling before I touched production. Back-and-forth conversations with Deviare's team. Questions about what data they actually needed. How they'd consume it. What their LMS expected. What would break if we got it wrong.

The temptation to jump in and start building was strong. I felt it. But that approach leads to rework, misaligned expectations, and frustrated partners.

Taking time upfront meant that when I finally did start coding, I knew exactly what I was building and why. No surprises. No pivots. No "actually, we needed something different."

Why Communication Mattered More Than Code

B2B integrations involve multiple teams, multiple systems, multiple priorities, multiple languages — and I don't mean programming languages.

Deviare had their own developers, their own timelines, their own constraints. Value Ed had business requirements and data considerations. I was the technical bridge between them.

Open channels for communication were vital. Regular check-ins. Clear documentation. Quick responses to questions. Willingness to adjust when requirements evolved — because they always evolve.

Technical skills get the code written. Communication skills get the project delivered.

I've come to believe that the ability to translate between technical and business stakeholders isn't a soft skill. It's a core competency.

Where It Ended

The integration passed through all development stages:

• **Development** — building and testing
• **QA** — quality assurance and validation
• **Staging** — final pre-production testing

Everything was ready for production.

But the broader partnership between Value Ed and Deviare didn't proceed — business reasons unrelated to the technical work. The APIs never went live.

And still, the project was a success.

The Words That Mattered

Here's what the Manager of Product & Quality Assurance at Deviare wrote afterward:

*"I am writing to commend the good work of Mpumelelo Mkhize, a developer at Value Ed, who recently assisted us in creating an API for our work readiness integration.*

>

*Throughout the project, Mpumelelo demonstrated professionalism, technical skills and commitment to our requirements.*

>

*Mpumelelo assessed our needs and executed an implementation plan that integrates the functionality to our platform.*

>

*I recommend Mpumelelo for any initiatives that require an experienced and meticulous developer.*

>

*Thank you once again to Mpumelelo and the Value Ed team for your assistance."*

That feedback matters more than whether the project went live.

It demonstrates that I delivered what was needed, the way it was needed, working effectively with an external team who had their own pressures and priorities. That's the job.

The Bigger Strategic Picture

This project was bigger than one integration.

As CTO at Value Ed, I saw this as our first attempt at offering sessions to external partners through their own platforms. If it worked with Deviare, we could replicate the model — universities, corporations, training providers.

The APIs I built weren't just for one partnership. They were a template for how Value Ed could scale its reach without requiring every partner's employees to use a separate app or website.

Building for the immediate need while creating infrastructure for future opportunities. That's strategic thinking. That's what technology leadership looks like.

What I Carry Forward

**Requirements first. Always.**

The urge to start coding immediately is strong. Resist it. Time spent understanding what you're building is never wasted. Time spent rebuilding because you misunderstood requirements always is.

**Communication is technical.**

Working with external teams requires more than code. It requires clarity, responsiveness, and the ability to translate complex concepts for non-technical stakeholders. These aren't extras. They're essential.

**Success isn't always about going live.**

This project didn't reach production. But I delivered working, tested, documented APIs that met requirements. The external team was satisfied. The technical work was solid.

Sometimes business circumstances change. That doesn't diminish the quality of what was built.

Why This Belongs Here

This integration showcases a different side of what I can do:

• **Backend API design** — not just frontend apps
• **B2B integration experience** — working with external teams and systems
• **Professional communication** — managing stakeholder relationships across organisations
• **Strategic thinking** — building for now while designing for later
• **Python/FastAPI expertise** — production-ready backend development

Not every project is user-facing. Some of the most impactful work is the infrastructure that enables partnerships, integrations, and scale.

This project shows I can do both.

---

Technical Summary

**Endpoints**: 7 API endpoints covering meetings, attendance, hosts, and webhooks

**Timeline**: Several months (including requirements gathering)

**Stages Completed**: Development → QA → Staging (ready for production)

**Key Learning**: Requirements first, communication always

---

*Need backend APIs or B2B integration work? [Let's connect.]*