SAVHN for Developers: Frequently Asked Questions

SAVHN exposes a real REST API — dozens of domains, all org-scoped, all bearer-token authenticated — documented as an honest index of what's actually deployed rather than a fabricated OpenAPI spec covering features that don't exist yet. This FAQ covers how to authenticate, where to find the documentation, what's currently available versus on the roadmap, and the practical questions that come up once you start building against it.

Access & Authentication

How do I get API access to SAVHN?

There's no separate developer signup or API-key request process — you authenticate the same way any user does: email and password against /api/auth/login, which returns a bearer access token. That token is what your integration uses for every subsequent request. Because it's your organization's real login credentials producing the token, API access is naturally scoped to whatever your organization is licensed and enabled for, with no separate developer-tier access to request or wait on approval for.

Is there a separate API key system?

No. There is no separate API-key system layered on top of user authentication — the same bearer token your users get from logging in is what your integration uses. This keeps authentication to one real, understood mechanism rather than two parallel systems with different security postures to reason about, and it means any authentication improvement made to the login flow automatically applies to programmatic access as well.

How do I authenticate a request once I have a token?

Send it as a standard Bearer header: Authorization: Bearer <accessToken>. Every response is scoped to your organization at the database level, so there's no cross-tenant data to guard against on your integration's side — a query against /api/crm/leads, for example, only ever returns your organization's leads, never another tenant's, by construction rather than by an application-level filter you need to trust.

Is the API org-scoped the same way the product UI is?

Yes — the same organizationId-based data isolation described for the product generally applies identically to the API. There's no separate, less-isolated data path available through the API that isn't also enforced in the UI, so building an integration doesn't introduce a weaker security boundary than the product itself has.

Does the API respect module entitlement and role permissions the same way the UI does?

Yes. API access to a given domain follows the same module entitlement as the product UI — if your organization doesn't have a module enabled, the corresponding API domain behaves the same way it would in the UI, and role-based restrictions on module visibility apply the same way to the account whose token you're using. There's no back-door API access to a module you haven't licensed or a role hasn't been granted.

Documentation & Domains

Where do I find the actual API reference?

The Documentation Portal (/docs) is the full developer guide, and /docs/api-reference specifically walks through the API in detail. The /developers page itself is an honest index — grouped by domain, showing whether each domain requires authentication or is public — cross-linked into that fuller documentation rather than trying to be the complete reference on its own.

How many API domains are there, and how are they organized?

The developer page lists domains grouped by functional area, each labeled with its base path (like /api/crm) and whether it requires authentication or is public. It's presented as a real, current index of what's deployed — not a spec describing aspirational future endpoints that don't actually exist behind the listing yet.

Are all endpoints authenticated?

No — some are intentionally public, such as endpoints supporting client approval links or lead capture forms that need to work without a login. Each domain on the developer page is explicitly labeled AUTH or PUBLIC so you know which kind you're dealing with before you build against it, and public endpoints are protected instead by per-key rate limiting rather than an authentication requirement.

Does SAVHN support webhooks?

Inbound webhook receivers exist today for connected providers — for example, payment gateway events and marketplace callbacks. Outbound event webhooks for your own custom integrations are on the roadmap rather than generally available today — worth checking the current status in the Developer Guide rather than assuming they're already shipped, since building an integration around an assumed webhook that doesn't exist yet would waste your time.

Is there a sandbox or demo environment for testing integrations?

The 7-day free trial gives you a real organization workspace — the same environment and API your integration would run against in production — so you can build and test against real (if trial-scoped) data rather than a synthetic sandbox with different behavior than production. This means what you validate during the trial is representative of production behavior, not a simplified stand-in.

What response format does the API use, and how are errors reported?

The API returns JSON responses consistent with the domains documented in the API Reference — the specific request and response shapes, including error formats, for each domain are best confirmed directly against /docs/api-reference for the endpoint you're integrating with, since the exact shape naturally varies by domain and resource type.

Are there rate limits on API usage?

Public-facing endpoints carry per-key rate limiting explicitly as an abuse-protection measure. For authenticated endpoints used by your own integration, current limits and any guidance on request volume for your use case are worth confirming directly with the developer team, particularly if you're planning a high-volume or bulk-sync integration.

Getting Help

Who do I contact if I have a technical integration question?

/book-demo?interest=developer-support routes specifically to the developer team, separate from a general sales conversation — use it when your question is about the API, authentication, or integration behavior rather than pricing or licensing.

Is the API reference kept up to date with what's actually deployed?

The developer documentation is explicitly built to reflect real, currently-deployed domains rather than a spec written ahead of the implementation — if something is described as available, it's meant to be checkable against the live platform, consistent with SAVHN's broader approach of not describing capabilities that aren't actually built yet.

Can I build a client-facing integration, like a custom portal, against the API?

Since the API is genuinely org-scoped and authenticated the same way the product itself is, building against it for your own internal tooling or a client-facing surface is a legitimate use — the specifics of what you're trying to build are worth discussing with the developer team directly, especially if it depends on functionality (like outbound webhooks) that's still on the roadmap rather than shipped.

Are there SDKs or client libraries available?

The API is a standard REST interface documented for direct HTTP use; whether a dedicated SDK exists for your language or platform is worth confirming with the developer team directly rather than assuming, since the honest answer depends on current status rather than what would be convenient to claim.

Is the API versioned, and how are breaking changes handled?

API versioning and change-management practices are exactly the kind of operational detail worth confirming directly against current documentation or with the developer team before you build a production dependency on a specific endpoint shape, rather than assumed generically — this matters most if you're planning a long-lived integration rather than a one-off script.

Can I use the API to build automations that trigger on events inside SAVHN, like a new lead or a closed ticket?

This depends on whether the specific trigger you need is exposed as an outbound webhook (currently on the roadmap rather than generally available) versus something you can achieve by polling the relevant domain's endpoints directly. For time-sensitive automation needs, it's worth confirming the current state of outbound event support with the developer team before architecting around an assumption.

Does every module have a corresponding API domain, or are some modules API-only-in-part?

The developer page's domain index reflects what's actually deployed and exposed today, grouped by functional area — the most reliable way to confirm whether a specific module's functionality is fully reachable via API, or only partially, is to check that domain's listing directly rather than assume full parity between every UI capability and its API equivalent.

If I'm building an integration for a client organization rather than my own, does anything change?

The API's authentication and org-scoping work the same way regardless of who's building the integration — a bearer token tied to a specific organization's login only ever reaches that organization's data. If you're building on behalf of a client, you'd typically need valid credentials for their organization (or an arrangement they've set up) rather than a separate partner-level access model, though partner-specific arrangements are worth discussing directly through /book-demo?interest=developer-support.

Where do I report a suspected bug in an API endpoint?

/book-demo?interest=developer-support routes technical issues, including a suspected API defect, to the developer team directly — worth including the specific domain, request, and response you observed so it can be verified against the real, current behavior of that endpoint.

Can I use the API to build my own custom reporting or dashboard on top of SAVHN's data?

Yes — since the API surfaces the same org-scoped data the product's own Reports module draws on, building a custom dashboard or reporting layer against relevant domains is a reasonable use of the API, subject to the same module entitlement your organization already has (you'd need the underlying modules enabled to have data to report on in the first place).

Does the API give me access to data across every module, or only specific ones?

The domain index on the /developers page reflects which functional areas have API coverage today, grouped by domain — the accurate way to confirm coverage for a specific module you care about is to check that module's corresponding domain in the index rather than assume every module has full API parity by default.

Is there a difference between the API my own product UI calls and the API documented for external developers?

The documented, publicly-indexed API domains are the same real endpoints the product itself is built on — the /developers page is described specifically as an honest index of what's actually deployed, not a separate, limited-access layer distinct from what powers the product's own UI.

How do I know if a given endpoint is stable enough to build a long-term integration against, versus still evolving?

The API Reference in the Documentation Portal is the most current source for this — for anything mission-critical to a long-lived integration, confirming current stability and any versioning guarantees directly with the developer team before building is more reliable than inferring stability from the fact that an endpoint currently exists.

Ready to build against a real API? Read the API Reference in the Documentation Portal, or start a 7-day free trial — no card required — to get a real organization and a working bearer token to test against. Configure the modules your integration needs through the Visual Pricing Configurator, and reach out to the developer team directly for anything the docs don't answer.