Connect Via Benefits Accounts data to your reconciliation, reporting and member-care stack
Via Benefits Accounts (package com.acclaris.mobile.acclaim, the Acclaris/WTW spending-account app) holds the kind of structured financial-health data that finance teams, TPAs and benefits dashboards need: HRA, HSA and FSA balances, reimbursement claim history and status, direct-deposit and card payment records, and uploaded receipts and legal documents. We deliver protocol analysis and a clean API layer over that data, modeled on Open Banking consent and data-sharing patterns.
What we deliver
Every engagement ends with something your engineers can run, not a slide deck. We hand over the protocol analysis report, the API specification, runnable reference source, tests, and the compliance notes a benefits-data integration needs. The two engagement models — source-code delivery from $300 (pay after delivery upon satisfaction) and pay-per-call access to our hosted endpoints — let you choose between owning the code or consuming a managed API.
Deliverables checklist
- OpenAPI / Swagger specification for every endpoint (login, accounts, claims, statements, documents, webhooks)
- Protocol & authorization flow report — token chain, refresh, device-binding and biometric-unlock handshake
- Runnable reference source in Python and Node.js for login, balance sync and statement export
- Automated test suite, sample payloads and Postman collection
- Compliance guidance: HIPAA handling, IRS Section 213(d) expense codes, GLBA safeguards, data-retention defaults
Two ways to engage
- Source-code delivery from $300 — you receive runnable API source plus full documentation; pay after delivery once you are satisfied.
- Pay-per-call API billing — call our hosted Via Benefits Accounts integration endpoints and pay only for the calls you make, no upfront cost; suited to teams that prefer usage-based pricing.
- Both models include a protocol-analysis report and a 30-day fix window for defects against the agreed spec.
Feature modules
Account & balance API
Returns every active spending account for a member — HRA, HSA, FSA, DCFSA, LSA, Commuter — with current balance, available-to-spend amount, employer contribution schedule and plan-year boundaries. Concrete use: a TPA dashboard that shows households a single consolidated balance instead of one screen per account.
Reimbursement claim API
Create, list and track reimbursement requests with line items, service dates, provider, amount, status (submitted / in review / approved / denied / paid) and any "documents required" flag. Concrete use: nightly export into an audit warehouse so compliance can sample denied claims and their reasons.
Statement & transaction export
Pull a date-ranged ledger of contributions, disbursements, reimbursements and debit-card transactions, exportable to JSON, CSV/Excel or PDF. Concrete use: month-end reconciliation that matches Via Benefits payouts against the employer's payroll and ERP entries.
Payments & direct-deposit API
Read direct-deposit configuration and payout events, and submit a payment to correct a negative balance, mirroring the in-app "make a payment" flow. Concrete use: a finance bot that detects overdrawn HRAs and triggers a corrective payment with an audit note.
Document & receipt pass-through
Upload supporting receipts and legal/account documents (the app accepts photos, Files-app uploads and Google Drive imports) and attach them to the right claim, with checksum and MIME validation. Concrete use: an OCR pipeline that pre-fills claim amounts before a human submits.
Auth, sessions & push events
Replicate the app's website-credential login plus fingerprint/face-unlock session model, with token refresh and device binding; subscribe to push-style events for important account activity. Concrete use: keep a member-care console signed in safely and notify agents the moment a claim needs documents.
Data available for integration (OpenData perspective)
The table below maps the data Via Benefits Accounts surfaces to the screen or feature it comes from, the granularity you can expect, and a typical downstream use. It is derived from the app's published feature set and from how comparable HRA/HSA/FSA platforms expose data through aggregation and Open Banking style consent flows.
| Data type | Source (screen / feature) | Granularity | Typical use |
|---|---|---|---|
| Account directory & balances | Dashboard / account summary | Per account (HRA, HSA, FSA, DCFSA, LSA, Commuter), per plan year | Consolidated balance views, eligibility checks, low-balance alerts |
| Contribution & disbursement ledger | Account activity / statements | Per transaction, dated, with type and source | Reconciliation against payroll/ERP, cash-flow forecasting |
| Reimbursement claims | Submit / review reimbursement requests | Per claim & line item: amount, service date, provider, status, denial reason | Audit trails, compliance sampling, member follow-up automation |
| Payment & direct-deposit events | Make a payment / direct-deposit setup | Per payout or correction, with method and timestamp | Accounting sync, negative-balance remediation, fraud monitoring |
| Debit-card transactions | Card activity (where issued) | Per swipe: merchant, amount, MCC, substantiation status | Substantiation tracking, IRS Section 213(d) expense classification |
| Uploaded documents & receipts | Upload documents (camera / Files / Google Drive) | Per file: type, size, linked claim, review status | OCR pre-fill, document-completeness checks, archival |
| Support tickets & notifications | Help center / push notifications | Per ticket & per event, timestamped | Member-care consoles, SLA dashboards, proactive outreach |
Typical integration scenarios
1 · Employer reconciliation of retiree HRA spend
Business context: a plan sponsor funds HRAs through Via Benefits and must tie every disbursement back to its general ledger. Data / API: the Account & balance API plus the Statement export, filtered by plan year. OpenFinance mapping: behaves like a consented account-information request — read-only, scoped to the sponsor's population, delivered as a normalized transaction feed the finance team can post.
2 · Claim-status notifications for members
Business context: a benefits-administration team wants members notified the instant a reimbursement is approved, paid or needs documents. Data / API: the Reimbursement claim API and signed webhooks emitting claim.approved, reimbursement.paid and document.requested. OpenFinance mapping: an event-driven data-sharing pattern that replaces polling with consent-bound push notifications.
3 · Receipt OCR & pre-filled claims
Business context: a digital-health partner wants members to snap a receipt and have a claim drafted automatically. Data / API: the Document pass-through endpoint to store the image, plus the claim-creation endpoint to draft line items from OCR output. OpenFinance mapping: a write-with-consent flow analogous to payment initiation — the integration prepares, the member confirms.
4 · Unified benefits dashboard across providers
Business context: a workforce uses Via Benefits for retiree HRAs and another administrator for active-employee FSAs; HR wants one view. Data / API: the Account & balance API here, aggregated alongside other administrators' feeds. OpenFinance mapping: classic data aggregation — many sources, one normalized schema, one consent record per member.
5 · Compliance audit & substantiation export
Business context: an auditor must verify that debit-card spend was on IRS Section 213(d) qualified expenses. Data / API: debit-card transactions joined to uploaded substantiation documents and claim records. OpenFinance mapping: a scoped, time-boxed read grant producing an immutable export package with hashes for evidentiary integrity.
Technical implementation
The snippets below are illustrative request/response shapes used during scoping. Authentication mirrors the app: a website credential exchange returns a short-lived bearer token plus a refresh token bound to a device fingerprint, optionally unlocked by a biometric assertion. Every endpoint returns RFC 7807 problem details on error, and list endpoints are cursor-paginated.
1 · Member login & session
POST /api/v1/via-benefits/auth/login
Content-Type: application/json
{
"username": "member@example.com",
"password": "<website-password>",
"device_id": "d3f1-...-9ab2",
"biometric_assertion": "<optional-webauthn-blob>"
}
200 OK
{
"access_token": "eyJhbGciOi...",
"refresh_token": "rt_8x2...",
"expires_in": 900,
"member_ref": "mbr_01HZ..."
}
401 Unauthorized
{ "type": "/errors/invalid-credentials",
"title": "Login failed", "status": 401 }
2 · Account balances & statement
GET /api/v1/via-benefits/accounts?member_ref=mbr_01HZ...
Authorization: Bearer <ACCESS_TOKEN>
200 OK
{ "accounts": [
{ "account_id": "hra_77",
"type": "HRA", "plan_year": 2026,
"balance": 1840.55, "available": 1840.55,
"currency": "USD" } ] }
GET /api/v1/via-benefits/accounts/hra_77/statement
?from=2026-01-01&to=2026-04-30&format=json
Authorization: Bearer <ACCESS_TOKEN>
200 OK
{ "transactions": [
{ "id":"txn_1","date":"2026-03-12","type":"reimbursement",
"amount":-126.40,"claim_id":"clm_55","status":"paid" } ],
"next_cursor": null }
3 · Claim webhook (signed event)
POST https://your-app.example.com/hooks/via-benefits
X-OFL-Signature: t=1715520000,v1=8b6e...
Content-Type: application/json
{ "event": "claim.approved",
"id": "evt_01HZ...",
"created": "2026-05-12T14:03:00Z",
"data": {
"claim_id": "clm_55",
"account_id": "hra_77",
"amount": 126.40,
"status": "approved",
"documents_required": false } }
# verify: HMAC-SHA256 over "{t}.{raw_body}"
# respond 2xx within 5s or we retry with backoff
# duplicate evt_* ids are safe to ignore (idempotent)
Compliance & privacy
Via Benefits Accounts handles protected health information and consumer financial data, so an integration cannot be treated as a generic web scrape. We work only under client authorization or documented, authorized interfaces, and we align deliverables with HIPAA (privacy and security rules for PHI, including Business Associate Agreements where we touch identifiable data), the IRS Section 213(d) definition of qualified medical expenses that drives claim substantiation, and the Gramm-Leach-Bliley Act (GLBA) safeguards expectations for financial-account data. Where card data is involved, handling follows PCI DSS scoping. For consumer-permissioned data sharing in the U.S., the direction of travel is the CFPB's Personal Financial Data Rights framework under Section 1033 of the Dodd-Frank Act — see the CFPB final rule on Personal Financial Data Rights — and our consent and revocation model is built to fit it. We apply data minimization, encrypt PHI and financial data in transit and at rest, keep consent and access logs, and sign NDAs on request.
Data flow / architecture
A typical pipeline is deliberately small: Via Benefits Accounts (client/session) → Ingestion & API layer (auth, rate-limit, normalization, consent enforcement) → Encrypted storage (tokenized account refs, ledgers, claims, document metadata; raw documents in object storage) → Analytics / API output (reconciliation feeds, dashboards, webhooks, CSV/PDF exports). Consent records and audit logs sit alongside every node, and a member can revoke access at any point, which invalidates tokens and stops further ingestion. Re-fetch cadence is configurable — hourly for balances, near-real-time via webhooks for claim and payment events.
Market positioning & user profile
Via Benefits (operated under WTW / Willis Towers Watson, building on the Acclaris spending-account platform) is a primarily U.S.-focused, B2B2C product: employers and plan sponsors contract the platform, and their retirees and employees use the app to manage HRA, HSA, FSA, DCFSA, LSA and Commuter accounts. The retiree-exchange side has run for roughly two decades and served well over two million retirees, and the portfolio keeps widening — for example, in 2025 MASA emergency medical transportation coverage was added to products available through the WTW Via Benefits exchange. Users skew toward Medicare-eligible retirees and HR/benefits administrators on the sponsor side; the app ships for both Android (package com.acclaris.mobile.acclaim) and iOS, with biometric login, a dashboard-first redesign, in-app document upload and direct-deposit setup. That mix — regulated health-finance data, an employer buyer, and a member-facing mobile surface — is exactly where an OpenData/OpenFinance API layer pays off.
Screenshots
Screens from the Via Benefits Accounts app. Click any thumbnail to enlarge.
Similar apps & integration landscape
Via Benefits Accounts sits inside a broad HRA/HSA/FSA and spending-account ecosystem. Teams that integrate one of these platforms usually end up wanting unified exports across several of them, so the apps below are part of the same integration landscape — listed here for context, not ranked.
HealthEquity
One of the largest independent HSA custodians; its app exposes HSA balances, investments and claim activity. Users who also work with HealthEquity often need a single transaction export that lines up with Via Benefits HRA disbursements.
Optum Financial / Optum Bank
Manages HSA, FSA and HRA accounts with receipt capture and bill pay. Reconciliation projects frequently span Optum and Via Benefits when an employer splits active and retiree populations across the two.
WageWorks / EZ Receipts
A long-standing FSA, HRA and Commuter administrator (now under the HealthEquity umbrella, with the EZ Receipts mobile experience). Holds claim and substantiation data that maps cleanly onto the same normalized schema we use for Via Benefits.
Lively
Offers HSA plus employer-sponsored FSA, LSA, HRA, Medical Travel and COBRA/Direct Bill accounts. Its multi-account model is a good example of why a unified balance API across providers is useful.
Forma
A flexible-benefits platform covering LSAs, FSAs, HSAs and HRAs on a card-first model. Integrators often want Forma lifestyle-spend data sitting next to Via Benefits health-reimbursement data in one dashboard.
Benepass
A card-first employee-benefits platform consolidating HSAs, FSAs, HRAs, commuter programs and post-tax perks. Holds pre-tax and post-tax transaction data that pairs naturally with HRA ledgers for full-picture reporting.
TASC — Universal Benefit Account
Combines FSA, HSA, HRA, commuter and lifestyle dollars on one card and app. Its single-account abstraction is conceptually close to the consolidated view many Via Benefits integrations are asked to build.
HSA Bank
A dedicated HSA custodian whose accounts are commonly aggregated via Open Banking style connectors. Often appears alongside Via Benefits when a household has both an employer HRA and a personal HSA.
Chard Snyder
A third-party administrator handling FSA, HSA, HRA and COBRA. Holds claim, balance and substantiation data of the same shape, so cross-platform audit exports are a recurring request.
Voya Health Account Solutions
Provides HSAs, FSAs, HRAs and related accounts as part of a broader workplace-benefits suite. Frequently part of multi-vendor benefits stacks where a unified data layer over Via Benefits and Voya is valuable.
About us
We are an independent technical studio focused on App interface integration, authorized API integration and OpenData/OpenFinance work. Our engineers come from banking, payments, benefits administration, protocol analysis and cloud backgrounds, so we understand HRA/HSA/FSA mechanics, HIPAA and GLBA expectations, and how to ship a financial-health API under real compliance constraints.
- Protocol analysis, interface refactoring and third-party API integration
- Open Data integration and automated data scripting / delivery of interface documentation
- Custom Python / Node.js / Go SDKs, test harnesses and webhook receivers
- Full pipeline: protocol analysis → build → validation → compliance review
- Source-code delivery from $300 — runnable API source plus documentation; pay after delivery upon satisfaction
- Pay-per-call API billing — hosted endpoints, pay only per call, no upfront cost
Contact
To request a quote or submit your target app and requirements, open our contact page. Tell us which Via Benefits data you need (balances, claims, statements, documents) and your preferred engagement model.
Engagement workflow
- Scope confirmation — which accounts, which data, which delivery format, which engagement model.
- Protocol analysis & API design — auth/token chain, endpoints, schema (2–5 business days, complexity-dependent).
- Build & internal validation — reference source, tests, sandbox runs (3–8 business days).
- Documentation, samples & test cases — OpenAPI spec, Postman collection, compliance notes (1–2 business days).
- Delivery & handover — typical first delivery in 5–15 business days; third-party approvals may extend timelines.
FAQ
What do you need from me to start a Via Benefits Accounts integration?
How long does delivery take?
How do you handle compliance, HIPAA and privacy?
Can you deliver real-time webhooks for new reimbursement claim status?
📱 Original app overview — Via Benefits Accounts (appendix)
The Via Benefits Accounts mobile app (Android package com.acclaris.mobile.acclaim, also on the App Store) lets members manage their reimbursement and spending account(s) anywhere, anytime, with intuitive navigation and a modern look and feel. A practical dashboard provides a quick summary of all account information, so members can review expenses and payments, get reimbursed and receive important updates. It brings the familiar Via Benefits website experience to the phone.
- Safe, secure and simple user login and registration using your existing Via Benefits website login and password
- Fingerprint or facial-recognition authentication for fast, secure sign-in
- Check an account balance on the go — built for busy lives
- Submit new reimbursement requests directly from the app
- Upload legal and account documents for review; take pictures or import supporting documents from the Files app or Google Drive
- Make a payment or correct a negative balance in the app, and resolve account issues easily
- Receive push notifications to stay aware of important account activity
- Get help fast — start a new help ticket or call account support with a tap, and manage all support in one place
Via Benefits is operated under WTW (Willis Towers Watson) and administers spending accounts including HSA, HRA, FSA, DCFSA, LSA and Commuter accounts; reimbursement accounts are typically funded by a former employer or plan sponsor, which sets funding and eligibility rules. Learn more about the underlying account type on Wikipedia's Health Reimbursement Account article. Via Benefits and Acclaris are trademarks of their respective owners; this page describes independent technical-integration positioning and is not affiliated with or endorsed by them.