01
Discovery is public
Docs, llms files, metadata, sitemap, and robots expose the product model without exposing customer data.
Residential HVAC missed-call recovery
Keep working. We’ll handle the callback.
Docs / Agent access
Machine-readable discovery is public. Protected actions remain narrow, attributed, and deliberate.
CallSnare is designed for business owners and staff first. Public docs help models and approved integrators understand the product, but protected write access stays limited and permissioned.
Public discoverability is there to reduce scraping and confusion. It is not the same thing as a broad machine-control surface.
Access model
Public understanding on the outside, scoped credentials on the inside
02
Protected access is explicit
External systems only act through org-scoped credentials created and managed by owners or admins.
03
Writes stay attributable
Protected requests remain permissioned, scoped, and auditable rather than broad and anonymous.
The product optimizes for operators first, approved machine work second.
Public today
Product docs, llms files, sitemap, robots, and page metadata.
Protected today
Scoped Bearer credentials for the narrow booking-focused private API.
Not public today
Broad lead, message, settings, and event-bus style external control.
Public discovery
Everything needed to understand the product without logging in
These public surfaces exist so partners, models, and owners can understand the operating model without reverse-engineering the dashboard UI.
`/llms.txt` and `/llms-full.txt` summarize the product for models.
`/docs/*` explains workflows, actions, permissions, security, and webhooks.
Structured metadata on public pages helps general machine understanding.
`robots.txt` and `sitemap.xml` include the public discovery surface.
Protected access
The current machine-facing surface is intentionally small
CallSnare exposes enough protected access for approved integrations to work with bookings and credential validation, but it does not hand broad product control to any external actor.
Owner or admin creates scoped Bearer credentials inside the product.
The current protected surface is the private booking API and health check.
Protected writes are org-scoped, attributable, and idempotent where needed.
Rotation and revocation are available from Setup > Integrations.
Current boundary
01Public discovery helps machines understand the product shape.
02Protected credentials let approved systems do specific, scoped work.
03Sensitive workflow control still stays in the main web app.
Not public today
The machine-facing surface is intentionally incomplete
This is what does not exist yet, even though the documentation vocabulary is already present.
A public agent card at `/.well-known/agent-card.json`.
A broad public write API for leads, messages, or settings.
A public outbound event subscription feed.
A public OpenAPI spec for the whole product.
What exists instead
The current system still supports real machine understanding
The absence of a broad public write API is deliberate, not a lack of structure.
Owner and staff UI for day-to-day work.
Public docs and llms files for understanding the product.
Org-scoped private credentials for approved booking integrations.
Audit logs, webhook logs, and lead events for accountability.
Continue reading
The next read is usually permissions, actions, or security
After the public-versus-protected split is clear, most readers want to know which actions exist, who can use them, and what guardrails make the surface safe.
Actions
See the action vocabulary and the difference between protected, internal, and planned capabilities.
Permissions
Review the role model, credential scopes, and tenant boundaries behind protected access.
Security
Understand authentication, authorization, rate limiting, validation, and audit posture.
Webhooks
See how provider callbacks feed the product and why there is no public outbound event bus today.