Liferay headless integration for apps, front ends and the systems behind them

Since DXP 7.1 Liferay has shipped a full set of headless APIs: Headless Delivery for content, documents, pages and taxonomies; Headless Admin for users, roles, workflow and sites; Objects for data models you define without code; a GraphQL endpoint over all of it; a batch engine for bulk import and export; and OAuth2 for securing every call. In 7.4 that grew into client extensions — custom-element front ends, JavaScript and CSS extensions, OAuth2 client profiles — that let a React app live inside a Liferay page without becoming a portlet. Liferay can therefore be used in three quite different ways, and the first decision on any headless engagement is which.

Fully headless: Liferay renders nothing; it is a content and identity service behind a Next.js site or a mobile app. Hybrid: Liferay renders the pages and owns navigation, permissions and personalisation, while individual experiences — a dashboard, a registration flow, a product configurator — are React or Angular components talking to APIs. Integration hub: Liferay is the front door, and the work is in the services behind it — ERP, CRM, core banking, GDS, building systems — reached through a Spring Boot integration layer and surfaced in the portal.

Our experience is that fully headless is right for a marketing site or a mobile-first product, and hybrid is right for almost every enterprise portal. Going fully headless with a customer or employee portal means rebuilding page composition, segments and personalisation, permission-aware rendering and search in the front end — the parts of DXP you are paying for. The hybrid pattern keeps them and still gives your front-end team React, TypeScript and a modern toolchain. We say which pattern fits in the first week, and we have talked clients out of a headless rebuild more than once.

Go headless — for a channel, not necessarily for the whole platform — when the channel is a native mobile app; when a public site needs static generation and edge caching that a portal render cannot match; when several front ends (web, app, kiosk, partner site) must show the same content and the same user state; when your front-end team is a React or Next.js team that should not have to learn portlets; or when another system, not a person, is the consumer of the content. PodEngine, Conscious Connects, CIGNEX and PIF Co-Builder were each one of these.

Stay hybrid when business users compose pages and campaigns themselves; when personalisation by segment, role, location and language is part of the product; when permissions must apply to every fragment on a page rather than to an API response; when workflows, forms and search are used through the portal UI; and when the portal is already large — the cost of re-implementing all of that outside Liferay is usually the cost of a second platform. Wipro, Bank of Baroda, Engineers India and Wego are hybrid: Liferay pages, modern components inside them, APIs underneath.

The cost of getting this wrong runs both ways. A portal rebuilt as a headless SPA loses page building and personalisation and gains a bespoke front end the business cannot edit. A mobile app bolted on to a portal with no API design inherits every page-oriented assumption — sessions, redirects, HTML fragments — and becomes slow and fragile. The assessment we start with exists to place each channel on the right side of that line before anyone writes code.

Every headless engagement is a version of the same picture. Front ends — a Next.js or React web application, a Flutter or React Native app, a partner's system — call APIs through a gateway or directly. Liferay exposes content, users, workflow and Objects through its headless REST and GraphQL endpoints. Where a channel needs data from more than one system, or logic that does not belong in the front end, a Spring Boot backend-for-frontend aggregates Liferay with the ERP, CRM or core system and returns exactly what that screen needs. Behind that sit the systems of record, reached through an integration layer that owns retries, mapping and monitoring. Search runs on Elasticsearch across all of it; caching sits in Redis and at the CDN for public content.

The choices inside that picture are what the assessment settles: REST or GraphQL per consumer (GraphQL for screens that compose many types, REST for simple and cacheable reads and for writes); Objects or custom modules for new data (Objects until the logic needs code); OAuth2 flows per client type; what is cached and for how long; how content changes reach a statically generated site (webhooks and on-demand revalidation); and how bulk data moves (the batch engine, not a script against the database).

• Front ends — Next.js / React web, Flutter / React Native mobile, partner and kiosk clients; TypeScript API clients generated from the OpenAPI and GraphQL schemas
• API edge — gateway or reverse proxy with rate limiting, TLS, WAF, request logging; CDN for public content responses
• Liferay headless — Headless Delivery and Admin REST, GraphQL, Objects, batch engine, webhooks on content and workflow events
• Backend-for-frontend — Spring Boot (or NestJS) services that aggregate Liferay and back-office data per screen and keep secrets off the client
• Integration layer — anti-corruption adapters for ERP, CRM, core banking, GDS, ITSM and IoT; idempotent retries, circuit breakers, dead-letter queues
• Identity — OAuth2 authorization-code + PKCE for apps, client-credentials for services, SAML / OIDC SSO to Active Directory, Entra ID or CAS
• Search, cache, observability — Elasticsearch, Redis, structured logs, traces and dashboards for every API and every integration

PodEngine had a web podcast platform on Liferay 6.2 and needed native-quality mobile: background audio, lock-screen controls, a custom radio-station builder and paid subscriptions. We built a Flutter app for iOS and Android against the existing Liferay REST APIs, added Braintree in-app payments and an offline queue, and shipped both stores from one codebase. It brought 35,000+ mobile-first listeners, an 18 % premium conversion rate, 2.4× longer sessions from the persistent mini-player and 4.6-star ratings within 60 days — on a Liferay version that predates the headless APIs, which is the point: a well-designed REST layer on the portal is enough.

Conscious Connects needed the whole event ecosystem — discovery, registration, attendee interaction, PayPal ticketing, social sharing — in one React Native app sharing the Spring Boot API with the web platform on Liferay DXP. CAS single sign-on removed a separate mobile login and lifted sign-in completion by 50 %; push reminders cut no-shows by 35 %; within three months the app drove 60 % of all new registrations. The lessons repeat across both: give mobile its own backend-for-frontend rather than reusing page-shaped endpoints; handle tokens and refresh properly; design for offline and for push from day one; and keep the store release process — signing, review, staged rollout — in the plan, because it adds weeks nobody budgets for.

Most of the value in a portal is in what it reaches. Sharp's customer service portal across 80+ countries connects to ERP and logistics through REST so that product registrations, warranty claims and firmware notices carry live status: warranty processing went from five days to 24 hours and 68 % of support tickets are deflected by self-service. Wego's partner portal ingests pricing feeds from 300+ airline and hotel partners through GDS integrations with automated validation, cutting pricing errors by 95 % and onboarding from three weeks to 48 hours. PIF Co-Builder's smart-workspace platform in Riyadh integrates the member app and operations portal with the building's IoT systems through headless and REST APIs, reducing physical service-desk load by 70 %. Bank of Baroda's risk platform ingests data from merged entities' core systems at three times the previous volume with zero data loss.

The patterns behind those numbers are unglamorous and non-negotiable. Every integration goes through an adapter that owns the mapping between the other system's model and ours, so a change on their side is a change in one place. Calls are idempotent and retried with backoff; circuit breakers stop a slow ERP from taking the portal down with it; scheduled synchronisation is used for reference data and events for anything a user is waiting on; every call is logged, traced and on a dashboard with an alert. Where the other system has no usable API — older ERPs, some banking cores — we build the integration on files, queues or database views and say so up front rather than promise real-time.

The hybrid pattern is where most of our headless work lands, because it modernises the experience without giving up the platform. Bank of Baroda's early-warning system moved to Spring Boot microservices and Angular portlets on DXP 7.4, with a maker-checker workflow to RBI requirements; risk-review cycles fell from two days to four hours. Wipro's employee portal uses React portlets for a responsive UI across 50+ country sub-portals. Engineers India's document platform surfaces Elasticsearch search and document-health dashboards in React; Wego's partner analytics are React portlets over REST data; ICICI Bank's migration converted MVC portlets to React on the way to 7.4.

On 7.4 we prefer client extensions over portlets for new work: a custom-element remote app is a plain React or Angular build, deployed and versioned outside the portal, dropped onto a page by a content editor, and talking to Liferay through the headless APIs with an OAuth2 client profile — no OSGi, no portlet lifecycle, no rebuild of the portal to ship a front-end change. Older versions get React or Angular portlets built as OSGi modules with the same discipline: no core modifications, business logic in services rather than in the UI, and every API versioned so the next upgrade is a platform change rather than a rewrite.

From our projects: exposing existing content and services through headless APIs to a new web front end takes six to ten weeks, including OAuth2, caching and a Next.js or React build of moderate size. A mobile app on a Liferay backend is three to five months from design to store release, with the backend-for-frontend and push notifications inside that. An integration programme connecting a portal to three to six back-office systems runs three to six months, usually in the order the business feels most. Modernising a portal's UI with React or Angular components alongside a version upgrade is folded into the upgrade plan rather than run separately.

Five things set the cost: the number of channels and how different their screens are; the size of the API surface and whether it exists yet on the Liferay side; identity — a single directory with OIDC is a week, four identity sources with CAS and SAML is a phase; the maturity of the back-office systems' APIs, which we cannot control and assess first; and mobile store and device requirements. Liferay version matters less than people expect: PodEngine's app runs on 6.2. We quote the assessment as a fixed fee and the build as a fixed price per phase with change control.

This work fits organisations that already run Liferay and now need a mobile app, a partner API or a modern front end without a re-platform: banks and financial institutions such as Bank of Baroda and CareEdge; global manufacturers with service portals such as Sharp; travel and media platforms such as Wego, Triton Digital and PodEngine; government and innovation programmes such as PIF Co-Builder; and any enterprise whose portal has become the front door to a dozen systems. If your platform is not Liferay, the same team builds the API and mobile layer on Spring Boot and Flutter or React Native — the broader practice is on the Liferay DXP services page.