Security
Control and guardrails
Your rules. Your off switch. Each change recorded with who made it. What you decide, what Tandem can't do, and how your records are kept apart. Only what's built today.
- Looks at your real schedule and books the visit.
- Saves what the caller needs on the pipeline.
- Only the caller's own visit.
- Never. Only people on your team can.
- Never. Only people on your team can.
Try the switches. Nothing here is saved.
What you decide
You pick who can do what.
Owner, admin, dispatcher, office and technician roles, or build your own and pick each permission. Changing someone's role or deactivating them takes effect on their next request. Only owners and admins change company settings, billing and the team.
Technicians see their own jobs.
A technician sees the jobs assigned to them and what hangs off them: their customers, estimates and invoices. A job that isn't theirs isn't there.
You set what the receptionist may do.
It has a short list of tools: look up a caller, check open times, book, log a lead, say what a customer owes, cancel a visit the customer asks to cancel, take a callback request, send the caller a link to their account, and hand off to a person. It can't change a price, write an estimate or invoice, take a payment or issue a refund. You write the rules it must follow, you set where handed-off calls go, and you can turn it off. A call with it stops at 10 minutes, and there are daily limits per caller and per company.
You choose which follow-ups go out.
Automations are ready-made, with their steps written out. You switch each one on or off. STOP and unsubscribe are honored automatically, and the receptionist won't answer a number that opted out.
Every change has a name on it.
Each change is recorded with who made it: a person, an API key or integration, the receptionist, the system, or a customer. Callbacks the receptionist took and visits it canceled show on Today under Customer activity. Webhooks you set up are signed, so you can check they came from Tandem.
Not built yet.
Approval cards and an undo button for what the receptionist does. Until then the limits above are the guardrails, and the off switch is yours.
How your data is protected
The measures the product has today, one by one.
Each company's data is kept apart.
Every record belongs to one company, and every request is checked against the company it's made for, in the web app, the tech app, the API and AI app connections alike.
Passwords and tokens are never stored as-is.
Passwords are stored as salted scrypt hashes. Session tokens, API keys and one-time links (invites, password resets, customer links) are stored only as hashes, so a copy of the database doesn't hand out working credentials.
Secrets are encrypted.
The tokens for services you connect and the secrets behind two-step sign-in are encrypted with AES-256-GCM. Recovery codes are stored as keyed hashes. In production the service won't start without its encryption and signing keys.
Two-step sign-in.
Anyone can add a code from an authenticator app to their password, with single-use recovery codes. Owners and admins can require it for the whole company and reset it for someone who lost their phone. Google and Microsoft sign-ins use that account's own security.
Sessions you control.
Sign-in uses one HttpOnly, SameSite cookie, sent only over HTTPS, that lasts 30 days. You can see where you're signed in and sign out any device. Owners and admins can sign a team member out everywhere, and a password reset signs out every other session. Writes are protected against cross-site request forgery.
Scoped API keys.
Keys can be limited to what an integration needs, set to expire (with a warning a week before) and revoked. AI apps you connect act as you, read-only by default, and see only what you can see.
Rate limits.
Sign-in, two-step codes, password resets, online booking, customer links and the AI features are rate-limited across every server.
Card details stay with Stripe.
Customers pay on Stripe's hosted checkout. We record the payment, never the card number.
Less data, kept for less time.
Technician location is collected only while they're clocked in or heading to a job, and location history is deleted after 30 days. This site sets no cookies and has no ads. Business websites we host run no scripts at all.
Report a problem
Found a security issue? Email hello@haestus.dev with what you found and how to reproduce it. Please give us reasonable time to fix it before telling anyone else, and don't access other people's data while testing.
More detail on what data we hold and who processes it: privacy policy and subprocessors.