API and integrations

The API documentation describes the technical surface behind web, mobile and integration workflows. It is publicly readable; business endpoints remain protected by authentication, API keys, tenant context, capabilities and permissions.

Open the API documentation

Authentication and tenant context

1. Use the existing session or the documented token endpoints for the web application.
2. Use X-API-KEY only for explicitly approved business integrations.
3. Send requests to the app domain for the correct product and tenant.
4. Check the capability and specific permission before write operations.
5. Treat tokens, cookies, API keys and webhook secrets like passwords.

A successful login alone does not grant access to every tenant or module. Product, host, active membership, capability and role permission are evaluated separately.

Publicly supported resources

The public schema contains only explicitly approved business resources: contacts, tasks, tickets, projects, comments, wiki, time entries, calendar events, files, folders and global search, plus leads, customers, deals and properties in insideCRM. Internal UI, sign-in, administration, real-time and webhook endpoints are not a public integration contract.

curl --request GET \
  --url "https://TENANT-HOST/api/contacts/" \
  --header "Accept: application/json" \
  --header "X-API-KEY: API_KEY_PLACEHOLDER"

Use only pagination, cursor and filter parameters described by the current schema. Before retrying a write operation, inspect the response, object state and documented idempotency behaviour.

Backend feature groups

The backend module inventory contains the complete customer-facing mapping with API route counts and support focus. Authorised administrators can use the complete internal schema at /api/internal/swagger/; it is not a public integration contract.

External integrations and webhooks

• Microsoft, Google and IMAP connect mail accounts and calendar data. OAuth callbacks must match the configured product domain.
• Microsoft and Google mail webhooks report changes that are then processed asynchronously.
• LiveKit transports internal calls and meetings. Its webhook keeps session, lobby and participant state current.
• Property portals receive object data and return status or enquiries. Credentials, property state and field mapping must agree.
• Brochure shares use expiring or revocable tokens and documented consent.
• Stripe processes payment methods, checkout, subscriptions and invoice events. Treat local state as confirmed only after the callback has been processed.

Recognise asynchronous processing

A successful request may only have accepted a job. This applies especially to mail synchronisation, sending, document indexing, portal synchronisation, notifications, reports and billing events.

For delayed results, check:

1. HTTP status and business response of the initiating request.
2. Request ID from the response or error page.
3. The affected object's status field rather than only the visible list.
4. Timestamp, timezone and latest successful synchronisation.
5. Only then retry; repeated write requests can create duplicates.

Classify error responses

Escalate safely

Provide product, full path without secret query values, timestamp with timezone, request ID, expected result, actual status code and a short reproducible sequence. Remove tokens, cookies, API keys, passwords, personal data and full payloads unless a protected support channel explicitly requests them.

See Troubleshooting and support diagnostics for more help.

Result

Integrators can find the current technical contract, support can assign an issue to the correct module, and protected calls remain access-controlled even though the documentation is publicly readable.