AxisCare
The #1-Rated Home Care Software With Unmatched Flexibility
What AxisCare does
AxisCare is an all-in-one home care operations platform for agencies. Day to day, teams use it to schedule and match caregivers, run EVV and mobile visit documentation, manage client and family information, track referrals and marketing, and handle billing, payroll, payments, and reporting. It is the operational system of record once a client, caregiver, or visit needs to be managed at scale.
Where AxisCare falls short
AxisCare covers internal marketing CRM, referral tracking, and client and family portals, but its public website-facing tooling is thin. We did not find public documentation for embeddable forms or widgets, a WordPress plugin, or webhook-based website sync. If you want a polished public site with SEO, custom intake, or immediate website-to-platform routing, you will usually need a custom front end or a CRM/iPaaS layer in front of AxisCare.
How we set AxisCare up
A visitor submits a Request Care form on your website. Your server validates the data, then uses the AxisCare site number plus a bearer API token generated in Admin > API Token to call the AxisCare API and create a Client record; a CRM like WelcomeHome can also trigger that sync once required fields are complete. As soon as the API call or CRM sync succeeds, the office can see the new record in AxisCare, finish service details, and move into scheduling and billing. Because we found no public webhook docs, any follow-up website automation should read from AxisCare on a schedule or via middleware rather than expecting native push events.
Integration method: rest-api
What AxisCare already owns
AxisCare is an all-in-one home care operations platform for agencies. Day to day, teams use it to schedule and match caregivers, run EVV and mobile visit documentation, manage client and family information, track referrals and marketing, and handle billing, payroll, payments, and reporting. It is the operational system of record once a client, caregiver, or visit needs to be managed at scale.
Primary users: Agency owners, office managers, schedulers, care coordinators, intake and marketing staff, billing and payroll teams, and caregivers using the mobile app daily; clients and families mainly use the portal.
Typical fit: Agencies of all sizes; AxisCare publicly prices by client count with tiers for up to 15 clients, 15-500 clients, 500-1,000 clients, and 1,000+ clients.
Core functions
- Schedule and match caregivers to client visits
- Run EVV, GPS-based clock-in and clock-out, and mobile visit documentation
- Manage client, caregiver, and family portal records
- Build custom intake forms, assessments, care plans, and reports
- Track referral sources, prospects, and marketing ROI with the built-in CRM
- Process billing, payroll, payer workflows, and payment collection
- Support communication, medication reminders, hospitalizations, and visit insights
- Analyze operations with business intelligence and customizable reporting
What still has to happen around AxisCare
AxisCare covers internal marketing CRM, referral tracking, and client and family portals, but its public website-facing tooling is thin. We did not find public documentation for embeddable forms or widgets, a WordPress plugin, or webhook-based website sync. If you want a polished public site with SEO, custom intake, or immediate website-to-platform routing, you will usually need a custom front end or a CRM/iPaaS layer in front of AxisCare.
No publicly documented embeddable website forms, booking widgets, or JavaScript snippets were found.
No public WordPress plugin was found on AxisCare's site or WordPress.org.
The Client + Family Portal is built for existing clients and families to view visits and billing, not as a public prospect-intake widget.
Public API materials expose core records such as Applicant, Caregiver, Client, and Visit, but we did not find a clearly documented website lead or prospect object for marketing-site capture.
API setup requires a site number plus an API token created inside each AxisCare site, and partner docs note some customers must contact support to enable the API Tokens page.
Public webhook docs now exist inside the official API reference, but public rate-limit and sandbox guidance still appears thin and some accounts must contact support to enable advanced features.
Website and CRM integration surface
Native website path
No publicly documented drop-in website widgets or embeddable forms were found. AxisCare's public materials emphasize internal modules such as Marketing CRM, Custom Forms, and the Client + Family Portal, plus partner integrations, rather than third-party website embeds.
Developer surface
- Public API
- Yes
- API style
- rest-v1
- Auth
- api-key
- Webhooks
- Yes
- Rate limits
- Not public
- Sandbox
- No
Integration patterns that make sense
Native First
LimitedUse this only if your 'website integration' is really just linking existing clients or families into AxisCare-owned experiences, or if staff are comfortable managing intake inside AxisCare's own Marketing module.
Your public site links people into AxisCare-owned experiences or staff-entered workflows. AxisCare then handles portals, forms, referral tracking, assessments, scheduling, and back-office work inside the platform, but we found no publicly documented drop-in widget for a third-party marketing site.
Api First
FitUse this when your website needs custom forms, multi-step qualification, server-side validation, deduplication, or immediate handoff into AxisCare.
Your backend stores the AxisCare site number, API version, and API token securely, then calls AxisCare's documented HTTP endpoints with Authorization: Bearer <token> to create or update records such as clients, applicants, caregivers, and visits.
Hybrid
FitUse this when SEO, content, and lead capture live on your own site or CRM, but AxisCare remains the operations system of record.
A website or partner CRM such as WelcomeHome captures the inquiry and required fields first. Once the record is qualified, a server-side or user-triggered sync pushes client and service data into AxisCare, where office staff complete onboarding, scheduling, billing, and care workflows.
Data objects your stack has to preserve
Create
Applicant, Caregiver, Client, Visit
Read
Applicant, Caregiver, Client, Visit
Update
Caregiver, Client, Visit
Who usually fits an AxisCare-centered website rebuild
Use this section to decide whether the website should qualify, route, or recruit before it hands data into AxisCare's REST API.
Best fit
- - Teams already running AxisCare as the system of record
- - Operators who need stronger qualification before data reaches AxisCare
- - Businesses that need a public site and intake flow shaped around health wellness demand
What operators complain about
- We still get a lot of calls about clocking in and out because the app says our caregivers are too far away even when they are standing at the client's home.
- We struggle with parts of scheduling because some features are less intuitive than we'd like.
- We have to pull up the full website on a phone and zoom in and out because the app doesn't give us all the admin views we need.
- We want the messaging side improved because communicating with staff inside AxisCare still feels limited.
- We lose visibility when removed shifts show on the client side but not clearly on the caregiver's calendar.
- We get stuck on enterprise QuickBooks setup, especially making sure locations map to the right line items or subaccounts.
Technical trust before you connect the stack
Native path
Managed intake + API
The website should only promise the AxisCare handoff paths that are publicly documented.
Auth model
Bearer token
If a custom handoff is needed, authorization into AxisCare has to stay explicit and documented.
API surface
REST API
AxisCare publicly documents its API and webhook surface, but the website still needs a cleaner intake layer than the native public handoff provides.
Auth: Public docs show a site-specific token flow, not an end-user OAuth flow. An admin signs into AxisCare, goes to Admin > API Token > Create New Token, copies the token, and your integration sends it in the Authorization header as a Bearer token. Some partner documentation notes that if the API Tokens page is not visible, AxisCare Support may need to enable it for that site.
Data flow: The safest pattern is website form to your server or CRM to AxisCare, not browser-direct calls. Middleware validates required fields, checks for duplicates, and then creates or updates AxisCare records such as Client or Applicant; after that, staff finish the operational work inside AxisCare. If a partner app is involved, some flows are user-triggered or scheduled rather than native real-time push from AxisCare.
Webhooks: AxisCare's official API reference includes a webhook section for real-time event notifications. Webhook subscriber configuration is not enabled by default for every account, so production webhook use may require support enablement before your endpoint can receive live POST payloads.
Security: AxisCare's public security materials say data is encrypted in transit and at rest, access to sensitive resources is restricted, and staff use multifactor authentication. Public docs do not describe granular OAuth scopes; the API token appears tied to an AxisCare site and site number, so keep it server-side, never expose it in browser code, and tightly limit who can generate or store it.
Also in the evaluation set
If AxisCare is on the table, these adjacent systems usually come up too. Use the CRM Scorecard to decide whether you need a horizontal CRM, a vertical operating system, or a cleaner connection between both.
AxisCare by industry
How AxisCare gets configured for specific operating patterns.
Not sure if AxisCare is the right fit?
The CRM Scorecard surfaces what your team actually needs from a CRM before you commit to one.
Take the CRM Scorecard