Solution for benefits platforms
Process eligibility, enrollment and census files without custom code
For benefits administration platforms, TPAs, carriers and the technology teams at brokers that receive files from employer groups and partners every week, and more of them during open enrollment.
FileFeed takes the eligibility, enrollment and census files each sender drops over SFTP or emails as CSV or XLSX, maps them to your schema once per sender, checks every row and delivers clean JSON to your API.
The input
Three file types, the same recurring problems
Each sender exports from a different payroll or HR system, or from a spreadsheet template someone made years ago. The content is the same. The layout never is.
Eligibility
One row per member or per dependant: member ID, SSN, name, date of birth, relationship, plan code, coverage tier, coverage start and end dates, employer group.
Census
One row per employee: demographics, hire date, salary, hours, location, and dependants either as extra rows or as repeated column groups.
Enrollment changes
Adds, terminations and changes since the last file, each with a change code and an effective date.
What breaks
Dependant 1 through 6 repeated across columns in one file, one dependant per row in the next
SSNs with dashes, without dashes, or with a leading zero that Excel dropped
Coverage dates as ISO, US, day first and Excel serial numbers
Tiers written as EE, EE+SP, EE+1, Family, Employee + Spouse
Plan codes that are the carrier's in one file and the employer's in the next
Terminations that arrive as a status, an end date, a change code, or a row that stopped appearing
Same meaning, different spelling
eligibility filestier
ssn
coverage_start
plan_code
status
Mapped and normalised once per sender. Every later file goes through the same rules.
The feed
One feed per employer or carrier, set up once
This is Automated FileFeeds applied to eligibility and census files. If you also take plain employee rosters, the HR tech page covers those.
- 1
Connection per sender
Each employer, broker or carrier gets its own SFTP folder on FileFeed, or you connect to their SFTP server. Senders who work by email get an allow list of addresses; attachments from those addresses are picked up.
- 2
Schema with the rules
Define your member schema once: which fields are required, which must be unique within a file (member ID), which take values from a list (tier, plan code, relationship), and the date fields.
- 3
Mapping, once
Upload the sender's first file. FileFeed suggests the mapping, you confirm it and add transforms where needed: trim, toNumber for salary, date normalisation for coverage dates, formatEmail for contacts.
- 4
Per row validation
Every row of every file is checked. Failing rows go into an error report with row number, field, value and reason, which you can send back to the sender.
- 5
Webhook JSON
Clean rows reach your endpoint as JSON, signed with HMAC. Your API applies them as new members, updates or terminations.
- 6
Runs
Each file is a run with rows in, passed, failed and what was delivered. Fix a mapping and reprocess the same file without asking the sender to resend it.
eligibility_v1
Upload a file to auto-generate fieldsUnique is checked within each file. Enum fields accept only the values you list.
Run
eligibility_weekly_2026-10-01.csvCompletedRows in
3,912
Passed
3,908
Failed
4
Export this report and send it to the sender, or fix the mapping and reprocess.
Validation
An error report you can send back to the broker
An eligibility file with one bad SSN should not stall the other 3,900 members, and it should not load the bad one either. Each run lists every failing row with the field, the value and the reason, in plain words the sender's payroll admin understands.
You forward the report. They fix the export, or you adjust the mapping on your side and reprocess the same file.
Checklist
Before the first eligibility feed goes live
- 1
Pick one sender and one file type. A weekly full eligibility file is the easiest start.
- 2
Write down your schema: fields, which are required, which are unique within a file, allowed values for tier, plan code and relationship.
- 3
Decide how dependants arrive, one per row or as repeated column groups, and which fields they map to.
- 4
Decide how a termination is expressed: coverage end date, status value, change code, or a row that stops appearing.
- 5
Agree the cadence and the channel with the sender: an SFTP folder or email from approved addresses.
- 6
Run the first real file, read the error report, send it back to the sender if their export needs a fix.
- 7
Confirm the webhook payload with your engineers once, then let the feed run.
On security: each sender's connection has its own folder and credentials, email intake accepts only approved senders, files are encrypted in transit and at rest, delivery is HMAC signed and every run and mapping change is in the audit trail.
Runs
Search files by any word…Reprocess any run after fixing a mapping. No re-upload needed.
FAQ
Questions benefits teams ask
Can we accept files from brokers by email?
Yes. Give the broker its own connection and approve the sender addresses. CSV or XLSX attachments from those addresses are picked up and run through that broker's mapping, validation and webhook. Mail from anyone else is ignored.
How are dependants handled?
Both common layouts work. If dependants come one per row, each row maps to a member record with a relationship field. If they come as repeated column groups (Dependant 1 name, Dependant 1 date of birth, and so on), each group maps to its own set of schema fields and arrives in the JSON for that employee's row. Your API decides how to store them.
What happens with a failing row?
It is recorded in the run's error report with the row number, the field, the value and the reason. You send the report back to the employer or broker so they fix the export, or you adjust the mapping or a transform and reprocess the same file. Nothing is silently dropped and nothing is silently loaded.
How do we handle weekly full files and change files from the same sender?
Set up one pipeline per file type on the same connection. The full file maps to your member schema and your API treats each row as an upsert. The change file has its own schema with a change code field (add, term, change) limited to allowed values, and your API applies each row as a delta.
How long does it take to set up the first eligibility feed?
Plan for one working session: create the connection, define the schema, confirm the suggested mapping on the sender's first real file and read the first run. The slow part is usually the sender scheduling the export, which is the same for any integration.
What does it cost?
$700 per month, flat, for up to 20 client connections, billed monthly. There is no per row pricing, so open enrollment volume does not change the bill.
Full plan details on the pricing page. Or book a demo and bring one employer's eligibility file with you.
Guides
Read before you build it in-house
Recurring client file feeds: the complete guide
The six parts of a feed that runs without an engineer.
Census files, field by field
Payroll and HRIS exports for benefits platforms.
Employee roster files
Recurring eligibility and roster feeds from client HR.
SFTP to webhook
From file drop to validated JSON event.
Or skip the reading: drop one real client file in your browser and see it mapped in about a minute.