Skip to content
Holidario Documentation

Integrations

Known product boundary This page explicitly documents something Holidario does not currently support. Do not treat it as an available procedure.

API and custom integrations: current availability

Understand the current programmatic-access boundary and request an integration without using internal routes or credentials.

For
  • I own or administer an agency
Available on
  • Agency

The Agency plan provides for API access and custom integrations, but Holidario does not yet offer a developer portal or a public, versioned, self-service API for connecting systems without prior coordination.

This is a documented limitation, not an instruction to look for hidden endpoints.

What is not available as self-service#

There is currently no supported public experience for:

  • creating and revoking tokens from the profile;
  • selecting token permissions or resources;
  • consulting a public catalog of endpoints and schemas;
  • registering customer webhooks;
  • working against a contractual test environment;
  • learning limits, versions, and retirement policy from public documentation.

Do not inspect or use internal interface calls as if they were a customer API. They may depend on a session, change without notice, or lack the security contract required for a third party.

What custom integration means#

From a need to an accepted integration
  1. Boundary No public self-service API Do not use internal routes, employee sessions, or endpoints discovered in the interface.
  2. Business Define the outcome Explain system, fields, direction, frequency, volume, users, and properties involved.
  3. Security Limit authority and data Separate read/write, resources, credentials, rotation, personal data, and retention.
  4. Reliability Design recovery Agree errors, retries, idempotency, partial synchronization, logging, and retirement.
  5. Approval Confirm feasibility and acceptance Holidario and the agency define tests, support, and conditions before touching real data.
Available only after confirmation Custom integrations in a plan do not mean a connector is ready or that secrets belong in the initial request.
Responsive visual summary; the complete content is also explained in the text.

A custom integration requires prior agreement on:

  • business objective and external system;
  • exact input and output data;
  • allowed team, properties, and resources;
  • read-only or write operations;
  • frequency, volume, and latency;
  • authentication, rotation, and revocation;
  • errors, retries, and idempotency;
  • personal data, retention, and responsible parties;
  • testing, acceptance, support, and retirement.

The fact that a possibility appears in the plan does not mean every provider already has a ready-made connector.

How to request one#

  1. Define the outcome you need, not only the system name.
  2. State which users and properties must participate.
  3. Separate data you only need to read from actions that must write or send.
  4. Provide the external provider's public documentation.
  5. Describe approximate volume and frequency.
  6. State whether it contains personal, financial, access, or guest data.
  7. Request a feasibility and security review from Holidario.
  8. Do not provide keys or secrets yet.

Holidario will confirm whether a compatible connector exists, whether specific work is required, and what tests or conditions apply. Until that confirmation, the integration must not be considered available.

Minimum criteria for accepting a connection#

Before production is authorized, your agency and Holidario must be able to answer:

  • Who owns each item of data?
  • How is the integration limited to the correct team?
  • What happens when a user or property is removed?
  • How is a credential revoked without losing control?
  • How is a duplicate booking, payment, message, or task prevented?
  • Where are failures recorded without exposing secrets?
  • How is partial synchronization recovered?
  • Who handles incidents and during which hours?

If any answer depends on sharing a personal password or granting unnecessary global access, the proposal is not ready.

Security#

  • Do not share passwords, session cookies, tokens, API keys, or verification codes in an initial ticket.
  • Do not grant access to every property when the case needs only some.
  • Use organization credentials with rotation and revocation.
  • Require an action log and a responsible person on both sides.
  • Treat reading and writing as different risks.
  • Do not test against real data until an acceptance plan is approved.

Alternatives while there is no public API#

Use exports, documents, and visible workflows that Holidario already supports for your module. If no alternative covers the case, request the integration and wait for explicit confirmation; do not automate the interface with an employee's credentials.

What to send support#

Include the external system, objective, required fields, flow direction, frequency, volume, affected properties, desired date, and technical contact. Do not attach secrets or real databases. You may include anonymized examples and the provider's public documentation.

Browse all documentation Press ⌘K or Ctrl+K from any page.

Preparing search…