Project context
A Technical Case Study — CodingBeings
Industry: Dental services | Role: Full-Stack Developer | Stack: Laravel, WordPress, REST API, JWT, OAuth, SSO, PHP
The Idea
A dental services client ran Laravel as their core application — where customers registered and paid for a subscription — while their actual content lived on a separate WordPress site with subscription-gated pages. The two systems had no connection: someone could sign up and pay inside Laravel, but WordPress had no way of knowing who they were or what they had paid for, so content access couldn't automatically reflect a customer's real subscription status.
What I Built
I designed Laravel as the single source of truth for both identity and subscription state, with WordPress automatically provisioned and kept in sync to match it.
Custom roles instead of a membership plugin
Rather than relying on a third-party WordPress membership plugin, I built two purpose-made roles — "Free Subscriber" and "Paid Subscriber" — with WordPress's own content-restriction logic keyed directly off them.
Provisioning and subscription sync
When a new user was created in Laravel, a REST API call automatically created the matching WordPress user as a Free Subscriber. When that same user upgraded and paid, a second API call promoted them to Paid Subscriber — unlocking gated content with no manual step in between.
One login, two systems
JWT-based SSO tied login together into a single experience: a user authenticated in Laravel was recognized in WordPress without a second login screen.
A custom plugin as the receiving end
I built a custom WordPress plugin that exposed the endpoints Laravel's user-creation and payment events called into, promoted users between roles accordingly, and validated the JWT tokens issued by Laravel to keep login state trustworthy across both systems. I also built a manual sync command runnable from Laravel to reconcile any individual user on demand.
Integration Architecture
Laravel owns identity and billing; a custom WordPress plugin keeps WordPress's roles in lockstep with whatever Laravel reports, with a manual recovery path for the rare cases where a provisioning call fails.
Laravel and WordPress subscription sync
Recovery path
- Provisioning call fails
- User exists only in Laravel
- Create matching WordPress user and run manual sync
- Identity and subscription roles reconciled
Laravel owns identity and subscription state. The recovery path is for rare provisioning failures.
View original diagram at full resolution
Scroll within the figure to inspect its original labels and connections.
Figure 1 — Laravel provisions and syncs WordPress roles via REST + JWT, with a manual sync command as a recovery path for rare provisioning failures.
Technical Highlights
Built two custom WordPress roles purpose-made for this system rather than adopting a third-party membership plugin.
Built a custom WordPress plugin exposing the endpoints Laravel's user-creation and payment events called into.
Implemented JWT-based SSO so login behaved as one integrated system across both platforms.
Solved a cross-mechanism session problem — WordPress cookies vs. Laravel's local-storage token — with a dedicated synchronization layer.
Built a manual reconciliation command as a safety net for rare provisioning failures, rather than leaving them as a silent gap.
Where the Project Landed
The pipeline ran reliably in production: a user could register and pay in Laravel and immediately see the content their subscription unlocked on WordPress, with no manual role assignment required in the normal case. Login worked as one fully integrated system across both platforms. The caching-related provisioning failure affected only 1–2% of signups at its worst, and each occurrence was resolved quickly with the built-in sync command rather than turning into an ongoing support issue. The system has now run with zero failures for four consecutive months.
Takeaways
This project is a good example of designing a clean single-source-of-truth integration between two different frameworks and two different authentication mechanisms, and of building a pragmatic recovery path for a known edge case rather than either ignoring it or over-engineering a guarantee of zero failures that the underlying infrastructure couldn't actually promise.