REST API vs SFTP file exchange for Italian payroll: what suits a mid-size EOR platform

Your platform needs to send Italian payroll inputs to a local provider and get results back. The question is how. REST API or SFTP file exchange. Both work. They fail in different ways and cost different things to run.

This article compares them on reliability, auditability and effort. The focus is a mid-size EOR platform with a real engineering team but not an unlimited one.

What actually moves between you and Italy  

Before choosing a transport, list the flows. Most platforms need the same set:

• New hire and contract data going out.
• Monthly variable inputs going out: hours, absences, bonuses, expense reimbursements.
• Payslip data and cost reports coming back.
• Corrections, cancellations and late changes in both directions.
• Status confirmations for statutory filings.

Some of these are batch by nature. Monthly inputs close on a cut-off and are processed together. Others are event driven. A new hire or a termination should not wait for a nightly job.

This split matters. It is why many platforms end up with both transports, not one.

Reliability  

SFTP is simple and old. A file is either on the server or it is not. There is no half-processed request. If your system is down when the provider delivers a file, the file waits. That is a real strength for batch work.

The weak points are quieter. A file can be partly written when the other side picks it up. A file can arrive with the wrong encoding or a changed column order. Nobody notices until payroll is wrong. You need naming rules, a completion marker, checksums and a clear rule for what happens to a rejected file.

REST API gives you immediate feedback. Each request returns a status. Validation errors come back in seconds, not after the next batch run. You can reject a bad record and accept the rest.

The weak points here are network failures and retries. If a request times out, did the provider receive it? Without idempotency keys, a retry can create a duplicate hire or a double bonus. This is solvable, but you must design for it from day one.

In short: SFTP is forgiving about timing and unforgiving about content. REST is strict about content and demanding about timing.

Auditability  

Payroll data gets questioned. By employees, by auditors, by your own finance team. You need to show what was sent, when, by whom, and what came back.

Files are natural audit objects. You can archive each one unchanged, hash it and attach it to a payroll run. When someone asks what you sent for a given month, you open the file. That is hard to argue with.

API calls leave a trail only if you build one. Log the full request and response, the caller identity, a correlation ID and a timestamp. Store them in a form that cannot be quietly edited. Done well, this is more granular than files, because you see each record’s individual history. Done badly, you have application logs that rotate away.

Whichever you pick, one rule holds. Every record needs a stable identifier shared by both sides. Without it, reconciliation turns into guesswork.

Effort  

SFTP is cheaper to start. Most payroll providers in Italy already support it. Your team writes an exporter, an importer and some monitoring. The hard part is the file specification and the error handling around it.

A REST integration costs more upfront. You need authentication, versioning, retry logic, rate handling and a sandbox for testing. The provider must also offer a stable API, and many local providers do not. If they do not, you will build the API yourself on top of their files, and then you carry both costs.

Ongoing effort differs too. File formats drift slowly and break loudly. APIs drift through version changes and break in subtle ways. Plan for a named owner on each side either way.

A practical recommendation  

For a mid-size platform, a hybrid is usually right.

• Use SFTP, or a file-style batch, for monthly payroll inputs and payslip returns. The cut-off model fits, and the archive doubles as your audit record.
• Use REST for event data: hires, terminations, status checks and confirmations. Fast feedback saves manual follow-up.
• Put one canonical data model behind both. The transport should be a detail, not a design.
• Require idempotency, record identifiers and a rejection report in both channels.

If your team is small and volume is modest, start with SFTP alone. Add REST for the flows where waiting hurts most. Do not start with a full API program unless the provider can support it properly.

Questions to ask any provider  

• How do you signal a rejected record, and how fast?
• What happens to a file delivered twice?
• Can you show the audit trail for a single employee change?
• How do you handle corrections after a payroll run is closed?
• Who owns the specification, and how are changes announced?

The answers tell you more than the transport label does.

Partnership teams that want to see how this works in practice can request the data-exchange specification.