Headless ERP for mid-market: why API-first beats UI-first at 100–2,500 employees

Enterprise software has two shapes. The big one is "UI-first" - a suite with a hardcoded interface and an API documented as an afterthought. The smaller one is "API-first" - a backend with no UI of its own, every capability exposed for any client. For mid-market companies, only the second one survives the first integration project.

What "headless" really means

Headless does not mean "has an API." Every modern product has an API. Headless means the backend has no built-in UI at all. The official front-end is one of many clients, and customers can replace it entirely without losing functionality.

In practice that translates into a handful of commitments:

• Every business capability is reachable from REST, GraphQL and gRPC, with OpenAPI 3.1 schemas published for every endpoint.
• Every state change emits a typed event on a Kafka-grade bus. Modules subscribe to each other's events instead of calling synchronously.
• The official UI is a thin layer of React micro-frontends. Customers may embed individual components, replace the whole UI, or use only the API.
• A single identity model spans modules - one employee, one customer, one supplier - so the backend stays consistent regardless of which client wrote the data.

The architectural commitment is not "we have OpenAPI." It is "the UI is not load-bearing."

REST + GraphQL + gRPC + Kafka - and why all four

Each protocol does a job none of the others does well.

• REST + OpenAPI 3.1 is the breadth interface. Every CRUD operation, every workflow trigger, every report request. Stable, cacheable, easy to script.
• GraphQL is the client-shaping interface. The mobile app needs a thin slice of the employee object; the analytics shell needs a wide slice with relationships. GraphQL stops the front-end from over-fetching and the backend from shipping five custom endpoints per screen.
• gRPC is the service-to-service interface. High-throughput, low-latency, strongly typed - used internally between modules and externally for any integration that cannot tolerate REST round-trips.
• Kafka events are the state-change interface. Anything that subscribes to "an invoice was approved" or "an asset crossed a maintenance threshold" hears it without polling.

Webhooks and Server-Sent Events handle outbound notification for clients that cannot consume Kafka directly. Standards over proprietary protocols: BPMN 2.0 for processes, DMN 1.4 for decisions, CMIS for content, OAuth 2.0/OIDC for identity, SCIM for provisioning, PEPPOL for e-invoicing, OpenTelemetry for observability. The boring stack that survives vendor cycles.

Replacing the UI without replacing the backend

The practical consequence is that mid-market customers buy capability, not interface. The branded employee self-service portal can be the customer's own React app. The supplier-facing portal can live inside the customer's existing extranet. The CFO's reporting surface can be Power BI hitting the headless analytics API.

Modules adopt incrementally - HCM first, ECM later, EAM when the maintenance contract expires - because no module forces a UI decision on any other. Integrations with existing ERPs, payroll providers, banks and authority systems are stable, well-documented, and survive backend upgrades thanks to the 24-month deprecation policy on every API and event contract.

The temptation in mid-market is to buy the polished demo. The right question is what the platform looks like in three years, after the brand has refreshed twice, after two of the modules have been swapped, after the IT team has built the integration nobody mentioned in the sales cycle. Headless is the answer that does not punish you for any of those choices.