There are two ways a platform puts employer of record into its own product, and they trade off against each other. White-labelling a provider's existing interface is fast to launch and slower to adopt. Building your own front end on the provider's API is slower to launch and better adopted. Which is right depends less on engineering capacity than on whose product your customer thinks they are using.
This page is for platforms and agencies weighing that build, not for employers buying EOR directly. If you are the employer, the employer of record pages are the ones you want.
White-label: the provider's interface under your brand
You take a working product and put your name on it. Your customer signs up through you. The screens, the flows and the logic are the provider's, restyled.
The appeal is obvious. There is little to build, so a launch is measured in weeks. Compliance stays with the provider. You are not maintaining a second product.
The cost is that it feels like a second product to your customer, because it is one. They notice the seam: a different navigation, a separate login, a support path that is not yours. That shows up as low adoption rather than as complaints. The feature exists, gets demoed, and does not get used, which is the worst outcome because it is the one that looks fine on a roadmap.
API-embedded: your front end, the provider's engine
You build the screens. The provider handles employment, payroll, contracts and compliance behind them. Your customer never leaves your product.
Adoption is better because there is no seam to notice. You control the experience, so EOR can sit inside a flow your customer already uses rather than beside it. If bundling employment into your product is a commercial strategy rather than a checkbox, this is usually the honest answer.
The cost is real work. You are designing flows for a domain with genuine complexity: country differences, contract states, onboarding that can stall on a document you do not control. You also take on a support surface. When a payslip looks wrong, the message arrives in your product first.
How to choose between them
Three questions settle it more reliably than a build estimate.
Is employment a feature or part of the proposition? A feature can live behind a white label. If your pitch is that customers run their whole workforce in your product, a visible seam contradicts the pitch.
Who does your customer blame? Whichever you choose, they will come to you first. If you are not willing to own the conversation, white-labelling does not protect you from it; it just means you have less ability to answer.
How many customers actually need it? If the honest answer is a handful, neither model pays for itself yet. Referring them and learning from the conversations is usually better than building, and it costs nothing to reverse.
What to ask any provider before you commit
Ask what the API actually covers versus what still needs a human, because the gap is where your timeline goes. Ask who is the legal employer and who appears on the employment contract, since that decides who carries the liability. Ask how a country that is not yet supported gets added, and how long that has really taken. Ask what happens to your customer's data and employees if you change provider later, which is the question nobody asks until it is expensive. And ask for the fee structure in writing, per employee, with any currency conversion shown as a separate line rather than taken inside the exchange rate.