Configure and use the Internal Support Agent

The Internal Support Agent is an optional chat that answers questions using only two sources: the current tenant's active private FAQs that the user may read and Holidario public documentation intended for that user type. It can also prepare selected Holidario-defined actions, but a mutation or email is never executed without a preview and your explicit confirmation.

The agency supplies one OpenRouter key for its tenant, contracts that account, and pays usage directly. Holidario provides the integration, lets the tenant choose a compatible model/ZDR-provider pair for this agent, and adds no AI usage charge. Before transmitting each new user message, Holidario checks it with its self-hosted Presidio service. Personal values supported by an authorized search are replaced with private search tokens; other detected personal or sensitive information blocks the request. Provider-safe conversations then use the exact saved endpoint with no fallback.

Knowledge boundary#

The agent does not read, index, or search conversations from staff, guests, reservations, tickets, WhatsApp, or SMS. It also does not browse the public web freely. It can search minimal metadata for authorized resources solely to generate links, but it does not use private descriptions, ticket or document bodies, messages, or arbitrary fields as a knowledge source. Some provider APIs offer built-in web search or URL retrieval, but Holidario does not expose those tools to this agent; public documentation comes from the validated local corpus.

At the start of an answer, the provider receives a compact catalogue containing every FAQ question the user may access, without its answer, and metadata for every public page intended for the user's effective audience, without page bodies. Holidario derives that audience on the server from the current tenant, plan, and roles; it does not accept an audience selected by the browser or model. The model selects specific IDs and Holidario rechecks tenant, audience, and permissions before retrieving only the needed answers or sections.

For Holidario features and workflows, the model must rely on sections or answers retrieved from that authorized catalogue, not on the provider's pretrained knowledge. A guessed slug from another audience behaves as not found: the boundary is repeated when listing the catalogue, opening a page outline, reading sections, and generating a link.

Holidario does not upload an FAQ file for the provider to scan. Attaching a file does not itself grant grep-style search: that would require another file or indexing tool, retrieved fragments would still enter the model context, and tenant isolation, updates, and retention would become harder to control. Retrieval remains inside Holidario.

Opaque references and provider-separated results#

Holidario runs product-resource searches with the real authorized values on its own server and separates each result into two channels. The AI provider receives only a short-lived opaque reference, generic resource type, a session-specific selection index, result count, and code-defined capabilities. It does not receive the database ID, admin URL, name, address, reservation reference, or other display text from the record.

The authenticated browser separately receives a card built from the original server-authorized result. That card may contain the exact link and complete display label because it is returned directly by Holidario under the current user and session; it is never reconstructed from model output. The model neither generates nor retrieves that second channel. If it attempts to print a product URL, Holidario rejects the response; FAQ and public-documentation links continue to use their authorized knowledge tools.

The mapping between each opaque reference and real record is encrypted and session-scoped. Later capabilities—such as opening a related payout, creating a ticket, or requesting an owner blockage—receive only that reference. Holidario resolves the ID internally and rechecks tenant, user, plan, permission, record authorization, relationship, and action settings before continuing.

A multi-page search also creates an opaque reference for the complete query, separate from each record reference and the page continuation. Holidario stores the resource type, normalized filters, and known total encrypted in the session; the model receives only the random reference, type, and count. The reference represents the authorized set matching that query, not a browser-supplied list of IDs. Resolving it reruns the query and rechecks the user, tenant, audience, plan, permissions, and authorization of every current result.

Collections expose their currently authorized, code-defined actions as choices after the results. Holidario can list any number of actions without preparing any of them; choosing one exact button creates only that action's confirmation proposal. Payout collections currently offer Download tax and earnings documents. Its proposal refers to the complete authorized query, so it includes every matching payout across every results page rather than only the cards currently visible. The preview records the complete count and a server-side fingerprint of that set. Confirmation reruns the query and refuses to proceed if the membership changed after the preview; it never accepts payout IDs supplied by the model or the browser.

Private guest links receive an additional boundary: the signed reservation URL is never sent to the provider. The model can only ask Holidario to display a delivery card. Holidario generates the URL later, when the authenticated user selects the card button, and returns it directly to that browser after rechecking the session, tenant, permissions, reservation, event, cancellation state, and check-out date. Before check-out the card delivers private guest access; after check-out it is clearly relabelled and delivers only the anonymized expired view enforced by the signed-route middleware.

For a proposed mutation, the provider receives this masked preview. The authenticated confirmation card loads the exact encrypted proposal separately from Holidario under the current user, tenant and session scope, so the user can still review the real change before confirming it without returning that complete preview to the provider.

Presidio + ZDR before the provider#

Immediately before preparing an external Internal Support request, Holidario sends the new user message—and, when present, the immediately preceding provider-safe assistant reply as recognition context—to its local, self-hosted Microsoft Presidio instance. The raw transcript is not repeatedly submitted to Presidio or rebuilt for the AI provider.

When Presidio detects a value that an existing read-only search can legitimately use, such as a guest name or reservation reference, Holidario replaces only that value in the provider copy with an opaque, short-lived token. The encrypted token mapping is bound to the current tenant, user, chat session, entity type, action, argument field, and expiry. The model can only copy the token into the matching private-reference field. Holidario authorizes the requested search before resolving the raw value in memory; the value is not returned in the tool result, continuation, resource context, or provider history.

The encrypted raw message remains available only inside Holidario for 60 minutes after the last chat activity. Later provider calls reuse the separately stored provider-safe copy, so a value entered during an earlier turn cannot cause an unrelated clean follow-up to be blocked by repeated full-history analysis. A private search token also becomes unusable after 60 minutes. Holidario deletes expired chat content with an automated cleanup every five minutes and expired token mappings with an hourly cleanup. Clearing the conversation deletes its messages and private token mappings immediately.

If Presidio detects personal or sensitive data that is not an allowed search input—such as credentials, payment data, or identity-document data—Holidario blocks the turn and sends nothing to the AI provider. Tokenization does not grant access: fabricated, altered, expired, cross-session, cross-user, cross-tenant, wrong-action, wrong-field, and wrong-entity tokens fail closed.

If Presidio is unavailable, times out, rejects authentication, or returns an invalid response, Holidario also blocks the turn. The error confirms that nothing was sent to the AI provider; try again later. There is no fail-open path.

The opaque references and authenticated cards described above remain an independent layer: they prevent database IDs, product URLs, and complete record labels from being sent to the model. They do not protect identifiers that someone types directly into the chat.

Histories that pass Presidio are sent with mandatory ZDR, the exact live-ZDR model/provider pair saved by the administrator, data collection denied, and no fallback. ZDR limits provider retention; it does not anonymize content. Router-side privacy still depends on the tenant administrator maintaining the OpenRouter account correctly. Follow Configure OpenRouter and AI conversation analysis, and do not enable Input & Output Logging, training, prompt publication, or the 1% data discount.

FAQ questions are part of the discovery catalogue, and retrieved answers or documentation sections reach the model so the conversation can work. Do not put personal data, secrets, or credentials in tenant FAQs.

Before enabling it#

You need:

• the Agency plan with AI messaging;
• read-ai-provider and update-ai-provider to configure the tenant;
• your own OpenRouter account with credits and quota;
• an OpenRouter API key dedicated to the tenant;
• all five ZDR controls on, all four Data Training controls off, and Input & Output Logging off;
• reviewed, active FAQs without unnecessary personal data or secrets;
• confirmation that users understand which personal values are accepted only for authorized read-only searches and that unnecessary sensitive data remains blocked;
• a decision on token budget, request limits, and allowed actions; chat-content retention is fixed by Holidario at 60 minutes after the last activity.

Complete the OpenRouter account, key, and ZDR tutorial first. Although FAQ answers are retrieved on demand, their questions are part of the catalogue sent so the model can discover what knowledge exists; review them to ensure that they contain no personal data.

Configure the BYOK provider#

1. Switch to the correct tenant.
2. Open Integrations > AI Provider, select Edit, enter the tenant's OpenRouter key, accept the mandatory ownership, DPA, transfer, and privacy-settings attestation, and save. If the key was already stored, you can attest it without entering it again.
3. Return to AI Agents and open Internal Support Agent.
4. Under Model for this agent, choose a model compatible with tools and reasoning.
5. Under ZDR inference provider, compare provider, quantization, context, maximum output, uptime, declared locations, and prices; choose a selectable endpoint.
6. Use Save model and provider.
7. Configure the agent's sources, limits, and actions, then use Save settings.
8. Use Validate connection before enabling it.

Validation sends one minimal request containing a real tool call. It checks the OpenRouter key, exact model/provider pair, and required capability together and may incur a small charge on the tenant account. Configured only means the key and route are stored.

The OpenRouter key is shared with the tenant's other agents. The route belongs only to the Internal Support Agent: changing it does not alter the model or provider saved for Conversation Analysis, SEO Content, Auto Blog, or another agent.

The first selector is loaded dynamically with models that the tenant key can use and that satisfy this agent's tool and reasoning protocol. The second is loaded from the current ZDR endpoint registry with endpoint-specific prices. Every technically compatible endpoint in that live ZDR registry is selectable.

The selection stores the exact model and endpoint tag. Every request sends both through an order + only route, requires zdr=true, denies data collection, and disables fallbacks. If the endpoint disappears or no longer satisfies policy, Holidario does not choose another provider: the route fails closed and an administrator must review and save another compatible ZDR pair.

Prices are displayed in USD per million tokens when OpenRouter publishes that unit. They can change after the catalogue loads and exclude credit-funding fees, taxes, and other account charges; confirm definitive costs in OpenRouter.

The tenant key is encrypted at rest and is never returned to the browser. When a key already exists, the edit field remains blank; leave it blank to preserve the saved key. Replacing the key or changing the model invalidates the previous validation.

The server applies the same policy as the interface: a crafted request or incompatible model is rejected before inference. Earlier direct credentials and dedicated profiles remain stored only as legacy compatibility data and are not offered in the primary configuration.

Choose sources, limits, and actions#

Before enabling the agent:

1. enable or disable Active private FAQs and Public documentation;
2. review the fixed automatic deletion notice: chat content expires 60 minutes after its last activity;
3. set requests per user per minute and per tenant per day;
4. set a monthly token budget or leave the internal limit unset;
5. enable only the actions approved by the tenant;
6. save the controls and enable the agent.

The budget is a Holidario token ceiling, not a monetary amount or a replacement for provider alerts. It is checked before each request, so one final bounded request may slightly exceed the threshold. Holidario totals usage across every tool step and, when the provider reports them separately, the cache or thinking tokens relevant to its billing; the provider dashboard remains the monetary source of truth.

Knowledge search and resource-link generation are read-only. Owner blockage requests, ticket creation, support email, and operation-description update are disabled by default and require confirmation when an administrator enables them. Enabling Request an owner calendar blockage also enables its read-only availability check; both tools remain inside the same action boundary.

Team-user access#

When the tenant enables the agent, any authenticated user whose current team is that tenant can open the menu and floating launcher. There is no additional chat permission to create, seed, or assign by user type.

This does not expand access to data or actions. Reading a FAQ still requires read-faq-item and current authorization for that FAQ; a user without that access may still consult enabled public documentation. Every resource locator requires its normal read-* permission, the plan feature where applicable, the current tenant, and per-record authorization. Tickets also preserve the categories visible to that user type. Every action retains its normal domain permission: confirming a proposal does not grant permission to create tickets or update an operation. If the agent, an action, or an underlying business permission is disabled after a proposal is prepared, confirmation is blocked.

Documentation by user type#

The chat uses the same canonical classification as the documentation site. An agency distinguishes agency administration, manager, front desk, property owner, cleaning employee, external cleaner, and external maintenance audiences. An individual owner uses a separate audience. A page may belong to one or several audiences, but the chat catalogue contains only pages that declare the user's effective audience.

For example, a property owner receives pages intended for property-owner; the catalogue omits, direct slug retrieval rejects, and the agent cannot generate a knowledge link to a guide exclusive to agency-admin. This classification limits what the agent may teach. Product permissions and per-resource authorization remain a separate boundary for every data lookup and action.

Private FAQs do not yet carry audience metadata. They are isolated by tenant and normal per-FAQ authorization, not by the public-documentation classification. An administrator should review who is authorized for each FAQ when it contains role-specific procedures.

Open the chat#

After saving and validating a compatible provider and enabling the agent, the floating Ask Holidario button appears for every user of the current tenant at the bottom right of dashboard pages. It remains a circle with the assistant icon and, on desktop, reveals its full label on pointer hover or keyboard focus. On desktop it opens the existing right-aligned floating window. On mobile it opens Holidario's full-screen modal: the header and message field remain fixed while only the middle conversation scrolls. The expand icon opens the full Internal Support Agent page on desktop only; it is hidden on mobile because the modal already fills the screen. Whenever you open the panel, Holidario scrolls the conversation to its newest message.

On iPhone, iPad, and other mobile devices, you can tap and type in the message field while Holidario finishes creating or restoring the session; Send becomes available when the authorized session is ready. If you dismiss the keyboard or move focus elsewhere, you can tap the field again as often as needed: every tap activates the field normally. You may also prepare the next message while the agent is replying, but cannot send it until the current response finishes. If the session cannot open, keep the text and use Retry after checking the connection.

The chat surface appears only when the user has an active current tenant and that tenant has the required plan, agent enablement, and a ready provider. Switching tenants rechecks every condition and keeps a separate browser session for each user and tenant. Each conversation is also bound to the effective documentation audience at the time it is created.

An empty chat shows quick-action buttons calculated on the server for that user. Holidario intersects the actions enabled in the tenant settings with the current plan features and normal business permissions. For example, Request an owner blockage is offered only to an eligible owner without direct calendar-management access, while Update operation description requires an operation-update permission. Internal companion tools such as the availability check do not appear as separate buttons.

Taxes & earnings appears only when the user may read payouts and the tenant has that feature. It opens a second step with a searchable Accommodation selector, From, and Through; both dates are included in the period. The selector loads only short-term-rental operations that Holidario allows the user to read. It defaults to All accommodations, which adds no operation filter; choosing one narrows the same search by both that authorized accommodation and the date range. The interface requires both dates, validates them, and prevents the final date from preceding the first. Pressing Find payouts builds one ordinary-language chat message containing the range and, when selected, the accommodation name. Presidio checks that new message before transmission and tokenizes a detected searchable value when necessary; a non-search sensitive detection blocks the request. The model interprets only the provider-safe message; Holidario then validates the tool arguments and rechecks configuration, plan, tenant, permissions, token scope, and record authorization before returning verified cards. This turn consumes tokens.

When at least one payout matches, the same answer shows What do you want to do with this list? and every collection action currently available to that user. It does not create a proposal yet. Choosing Download tax and earnings documents prepares one confirmation card only when the complete set is within the batch limit. This is a document export only: it does not file taxes, calculate a return, or create an earnings report. The resulting card clearly covers every payout in the authorized search, including later pages.

Find something opens a second, plain-language step listing only the types enabled for this chat that the current user may read: Accommodation, Reservation, Payout, Ticket, Cleaning task, and Accommodation expense. Accommodation replaces the earlier “Operation” and “Accommodation” choices: it always searches the authorized short-term-rental operation, not the technical property record. Choosing one immediately sends a code-defined natural-language message, and the assistant then asks for the name, date, reference, or other missing search detail. All available resource types, including Reservation, remain a normal provider conversation: the model interprets the user's text and calls the matching code-defined lookup tool. No quick action sends an internal action key, grants permission, or executes a mutation by itself; the selected lookup or action still rechecks the resource type, tenant, record, arguments, authorization, and confirmation requirements.

For a user with the Cleaning employee or External cleaning provider role, Find something > Cleaning task opens a third step. Assigned to me today (DD/MM/YYYY) sends a natural-language request containing the current operational date; the server derives the employee or provider identity linked to the account, searches only that worker's authorized assignments for the day, and returns links to the cleaning work view. The model receives and chooses no user, employee, provider, tenant or assignee identifier. A follow-up asking for another date keeps the assignment scope and sends only the normalized date to the same assignment-filtered server lookup. Find another cleaning task opens the distinct general search; an exact-date general search may return any tasks the user is authorized to view, and those results are not evidence that the tasks are assigned or not assigned to that user. “My tasks”, “assigned to me”, and “tasks I have been assigned” select the personal lookup; “all tasks” or “all assigned tasks” without “to me” select the general list. Every returned task has a server-verified card with Open, independent of the model's Markdown. Its authenticated-browser label is the complete related operation name, not an automatically generated cleaning-task title. Both the “assigned to me” shortcut and its provider tool are absent for other roles or accounts without an active linked cleaner identity, even when they may read cleaning tasks for another business reason.

The agent does not continue a search in the background after a response ends. Once it has the date and scope—for example, all authorized tasks on 05/08/2025—it must execute the search in that same message and return the first page of cards, report that no authorized matches were found, or ask for the one detail that is genuinely missing. If the model only says that it is searching, checking, or processing without calling a tool, Holidario discards that text and retries the turn once with an explicit requirement to complete the lookup. If it omits the lookup again, the chat shows a recoverable final error instead of leaving an apparently pending search.

When a search returns exactly one resource, Holidario displays Options for this resource whenever at least one capability remains allowed. Read-only retrievals appear under Look up—for example, obtaining a guest check-in link or viewing a payout amount, recorded date, deducted charges, or channel breakdown—while effectful operations appear separately under Actions. A query is neither presented nor accepted as an action. Collections reuse the same card as What do you want to do with this list?, limited to actions over the complete result set. Empty sections are not rendered. The model does not build this card, reproduce its options as a Markdown table, or decide which buttons exist.

The recent reference, its selection index, type, real ID, and complete label are stored encrypted inside the Holidario session. Each index is unique for that session and is not reused when an earlier reference expires. The assistant can reuse the opaque reference for up to 60 minutes; after that it is omitted, and the encrypted chat record is deleted by the same short-lived retention process. Clearing the chat or changing documentation audience makes the earlier session inaccessible. The provider receives only the opaque reference, type, index, and bound arguments that also contain that reference—never the ID, label, or link. Before displaying the chooser and again when an action is pressed, Holidario rechecks tenant settings, plan, permissions, the reference, and record or collection authorization.

Pressing a resource action makes the authenticated endpoint focus that exact reference again, even when the card belongs to an older answer. If the action still needs human details—for example, a ticket reason, blockage dates and reason, or a replacement description—the chat sends the code-owned guided wording and the agent asks only for those details. If a collection action already has every required argument, its button prepares the confirmation card directly. Choosing a button never performs a mutation without the later explicit confirmation.

A lookup with exactly one match focuses it unambiguously and automatically displays its available queries or actions. When several matches are returned, none replaces an earlier choice until the user chooses one. Every indexed card includes Select. Pressing it sends the same index as structured data; Holidario checks that it belongs to the encrypted session, remains current, and still identifies a record that the user may read. The response and options card are generated directly by Holidario, with no model request or token use. The provider receives selected_resource only on the next turn that genuinely needs it. A later lookup replaces or clears that focus so an old choice is not reused accidentally.

Typing a card's name, position, or number in chat does not replace this selection because the model cannot see card labels. A typed name starts a new authorized lookup; use Select to choose among results that are already displayed. Repeat the search if the card has expired.

Loading an ordinary dashboard page does not create a chat session or call the provider. Holidario restores or creates the conversation only when you press the floating button. Closing the panel does not immediately delete the conversation; reopen it within 60 minutes of the last activity to continue it.

To remove the visible history, press Clear conversation and confirm Clear and start over. This remains available while a reply is processing, including when a browser refresh has left the chat apparently stuck. Holidario interrupts that reply, deletes the messages, cancels pending proposals, and archives the previous session before creating a new empty one; a late provider response cannot reappear in the new conversation. Action security records and usage accounting remain under their separate retention periods. Closing the prompt with Keep conversation changes nothing.

If a role change gives the user a different documentation audience, Holidario does not restore or reuse the earlier conversation: it starts a new chat and never sends the prior role's answers back to the model. The old conversation remains retained until its normal expiry but is not accessible from the new audience. The same fail-closed rule applies to sessions created before audience classification existed.

Ask and verify an answer#

1. Press Ask Holidario or open Internal Support Agent from the menu.
2. Ask one specific question, or choose one of the quick actions currently available to you. For a resource link, choose Find something and then select the type you recognize. To review payouts for an exact range, choose Taxes & earnings, leave All accommodations selected or choose one authorized accommodation, select the inclusive first and last dates, and press Find payouts.
3. Review the Sources links shown with the answer.
4. Open the FAQ or public page when the answer affects an important decision.
5. If evidence is missing, rephrase the question or work from the original product screen.

The server generates source titles and links from retrieved IDs; the model cannot create a valid arbitrary URL. It can still summarize incorrectly, omit conditions, or fail to find the right source.

Assistant replies support Markdown for readable paragraphs, headings, lists, emphasis, quotations, code, and tables. Holidario converts and sanitizes that content on the server: model-supplied HTML and images are removed, and only links to the current Holidario application or Holidario public documentation remain clickable. External or unsafe destinations appear as text. Your own messages always remain plain text.

You can also request an accommodation link by name, partial name, or ID. Although the interface says Accommodation, Holidario always searches the authorized short-term-rental operation. It runs a bounded search inside the current tenant and applies the normal read permission and resource authorization before generating each link. If several records match, the agent should show the choices so you can identify the intended one; an empty result never reveals whether an operation exists in another tenant or outside your authorization.

Reservation search accepts a guest's full name or an exact Booking.com, Airbnb, or Holidario reservation reference through the private-token path. Presidio replaces the detected value before the message reaches the provider; the reservation tool receives only the opaque token, rechecks the authenticated user's normal reservation access, and resolves the value only for that bounded search. Do not include payment data, identity documents, credentials, or unrelated personal details—the turn is blocked when those detections have no authorized search use.

You can also ask which reservation is staying at an accommodation today or on another date. Holidario first finds the authorized operation by name, then uses its opaque reference to locate a non-cancelled reservation whose range covers the date (check-in ≤ date < check-out); check-out is exclusive. “Now” and “today” use the server's operational date. You do not need to know the guest or confirmation code. This capability is offered and runs only while the user retains read-reservation, read-event, access to the operation, and authorization for both the resulting reservation and its event. If inconsistent data creates an overlap, the browser shows every authorized match for the user to choose; the model receives none of their names, IDs, or links.

Continue from a found resource#

Next steps are declared in code by resource type. They may be read-only queries or effectful actions; they are not a generic CRUD tool, and the model cannot invent another operation. Queries appear in their own section and may also be requested in ordinary language. For example, for an accommodation operation you can look up the reservation staying there today or on another date, or its most recent payout. For a reservation you can look up its private guest check-in link, associated payout, or related cleaning task. When the user may create tickets and the tenant enabled it, Create a ticket about this resource appears separately under Actions. Each capability remains available only while the tenant feature is active and the user retains the corresponding read or write permission and authorization over the resource and its relationships. Holidario rechecks every boundary when it is used, resolves relationships on the server, and returns the exact card or proposal; the model does not search for or infer the related record. If it is absent or unauthorized, the capability is unavailable. An operation may offer a notes update or owner blockage request as actions only when its own permissions and business rules are satisfied.

When you ask for “the latest payout for Almería 11”, the agent first finds that operation and uses only its opaque reference. Holidario resolves the operation on the server, restricts the query to its payouts, sorts by the newest creation date, and returns at most one card. You do not need to supply a month and year, and this lookup never falls back to the tenant's latest payout. If no authorized payout exists for that operation, it returns an empty result instead of showing a payout from another accommodation.

After finding a payout, you can ask in ordinary language when it was recorded, how much was paid, which charges were deducted, or how much came from Airbnb, Booking, and the other channels. The agent selects only one of those four capabilities and returns the payout's opaque reference; Holidario recalculates the exact values and displays them solely in a financial card in the authenticated browser. The date, amounts, charge descriptions, channel names, database ID, and admin URL are not sent to the model or reconstructed from its prose. If the model says the detail is available in a card without executing the corresponding lookup, Holidario discards that answer and requires it once to use the exact capability; if it omits the call again, the chat shows an honest error instead of inventing a card.

Each answer has a deliberately bounded meaning:

• Recorded date: shows created_at using European date notation and the operational time zone. It proves when Holidario created the payout record, not when a bank credited the funds.
• Final net payout: shows the included net reservation income, deducted expenses, and final manual payout. Amounts paid directly by a channel through an automatic split are not added to that manual payout.
• Deducted charges: uses the immutable snapshot saved when the payout was created. It shows totals for channel commissions, agency fees, cleaning charges, and other expenses. With read-property-expense, it also itemizes accommodation expenses the user can still read and included owner-blockage cleaning charges; without that permission, totals remain visible but those descriptions do not. The snapshot does not store a reliable historical relationship between every cleaning charge and a specific task, so the card does not invent a task list.
• Income by channel: groups the payout's net reservation income by Airbnb, Booking, direct booking, or another channel. The card distinguishes income included in the manual payout from income paid directly by a channel. It does not allocate accommodation expenses across channels because the payout does not contain that allocation.

All four capabilities require read-p-m-s-payout, the payout plan feature, the current tenant, and authorization for that payout. Holidario rechecks those conditions when offering the options and when constructing each card. Open full payout remains available for reviewing the original record afterwards; opening it is not required to see the requested answer.

To obtain check-in access from a found reservation:

1. ask “Give me the private guest check-in link for this reservation”;
2. check that the clearly named capability card appears;
3. select Prepare private link so the server revalidates the reservation and generates the signed URL;
4. use Open private link to inspect it or Copy private link to share it through an approved channel. For a past stay, the offered capability says Get the reservation link (anonymized view; check-in is no longer available) and the card is headed Past reservation: check-in unavailable.

Before scheduled check-out, this link is a passwordless access credential. Do not publish it or paste it back into the chat. At check-out, private access expires. For an authorized, non-cancelled past reservation with a check-out date, Holidario can still generate the correctly signed route, but the expired-signature middleware renders only an anonymized historical shell: it hides the reservation reference and private fields and disables check-in and the guest area. Cancelled reservations, records without a check-out date, and reservations or events the user cannot access remain unavailable. The card does not require confirmation because generating the link does not modify the reservation; any capability with an effect keeps its normal preview and explicit confirmation.

Find other authorized resources#

The same read-only locator supports a closed set of types and identifiers. The model cannot supply a table, class, field, or URL; Holidario defines every query and every returned field in code.

Resource	Accepted identifiers
Accommodation	Name, partial name, or ID of the short-term-rental operation.
Payout	ID, descriptive text, or operation name; also an exact range with inclusive first and last dates, one whole calendar year, or a creation month and year, optionally narrowed by operation. For an accommodation's “most recent” payout, use its operation-bound capability without a period.
Ticket	Subject or ID; also creation month/year and exact status. It does not search the body or conversation.
Cleaning task	ID, reservation reference, or operation name; also scheduled month/year and exact status.
Accommodation expense	Description, property, or ID; also one whole calendar year or an expense month/year, with an optional operation.

Chat searches for issued invoices, supplier bills, shared documents, received tax expenses, companies, contracts, direct-booking payments, VeriFACTU submissions, rate plans, and discount coupons are disabled. Even when the user may read one of those resources on its normal Holidario screen, the agent neither offers nor accepts that type in its tool; use the corresponding dashboard section instead.

Payouts support an exact range with both endpoints included, a whole calendar year, or a month and year lookup. Accommodation expenses support a whole year or a month and year. Payout periods use the existing creation date (created_at) in the operational time zone, while accommodation expenses use their own expense date (date), so no period column needs to be added or backfilled. If you ask for “all payouts in 2025” or “all accommodation expenses in 2025,” the agent runs the annual lookup immediately and returns the first page with the exact total; use the numbered controls for the remaining pages. It neither asks for a month nor runs twelve searches. Ticket and cleaning-task period searches still require month and year and cover one calendar month.

The locator returns bounded pages of up to ten choices—five by default—and shows the exact total of authorized matches with the current page. Every result is rendered as a separate server-verified card with Select and Open; the floating panel keeps one column, while the full-page chat lays cards out in a compact grid as space allows. The provider knows only the session index and opaque resource references: it cannot see a result label or print the admin destination in Markdown. Numbered controls appear under the cards, like ordinary Holidario lists, with previous, next, and ellipses when many pages exist; the compact window keeps the immediately adjacent page visible before an ellipsis. Pressing a page number sends only the visible natural-language message, such as “Show me page 7 of this search”; typing the same message follows the identical conversation path. This is a normal provider turn and therefore can consume tokens. The prompt exposes only the current resource type, page, exact total, and final page. Whenever that state exists, the model receives a dedicated read-only page tool whose only argument is the requested page number; the encrypted continuation, original filters, and result labels remain entirely on the server. The general search tool cannot accept pagination arguments. This keeps arbitrary wording unambiguous without matching a particular sentence and avoids asking the provider to reproduce an encrypted value. A server evidence check rejects and retries any provider response that claims a different page was loaded without the matching authenticated page result. The server-held continuation remains available on the last page, so a later request can move backward without repeating the search. It is bound to the current user, tenant, documentation audience, chat session, and expiry, and cannot broaden the original filters. The server reapplies the resource-specific read permission, subscribed feature, tenant, per-record authorization, and every additional visibility rule. After a numbered click finishes rendering, the shared chat keeps the generated page-request message at the top of the visible conversation so the new results follow it. If records changed, the total and page count are recalculated; if the page or server state is no longer valid, repeat the original search. An empty result does not establish that the record does not exist.

The opaque complete-query reference is separate from the server-held pagination state and the individual cards. It retains only the base lookup without an offset and lets each declared collection action resolve all authorized records even when they span several pages. The authenticated result card lists those actions dynamically; if two are enabled, it shows two choices and prepares only the one selected. For Download tax and earnings documents, the confirmation preview is tied to the complete payout membership at that moment. If a matching payout is added, removed, or ceases to be authorized before confirmation, Holidario rejects the stale proposal and the user must repeat the search. The model must not offer to file taxes, calculate a return, create an earnings report, or perform an undeclared action on that reference.

The complete authorized catalogue—including only pages for the effective audience—is included again so the model knows every option. Provider instruction caching may reduce part of the repeated cost when available, but this depends on its policy and billing. Only selected FAQ answers and documentation sections enter as retrieved content.

Prepare and confirm an action#

Describe the intended result in your own words. The agent infers the subject, description, and reasonable technical values; it should not begin by exposing internal fields, enum values, or a questionnaire. If a mandatory detail cannot be inferred safely, it asks only for that detail.

The agent distinguishes between a request that this chat cannot perform and a supported action that only needs more information:

• when the exact request is unavailable, it says so directly—“this cannot be done through this chat”—and may suggest at most two alternatives that are enabled and authorized for the current user;
• when the action is available but a detail is missing or cannot be used safely, it explains the boundary in ordinary language and asks one focused question. It keeps usable details already supplied and does not ask you for field names, lookup types, or other technical terms.

The agent must never silently broaden, narrow, split, or substitute a rejected request. A whole-year payout or accommodation-expense search, for example, runs as one paginated query and is not converted into twelve monthly calls. For a resource that supports only a monthly period, such as “all tickets in 2025,” it retains the year and asks “Which month of 2025 would you like me to check first?” instead of choosing a month or returning a different period.

The Taxes & earnings shortcut prepares only the period search. When results exist, choose Download tax and earnings documents under What do you want to do with this list? Holidario then prepares that proposal—never every available collection action automatically. Review its payout count, period, and all-pages scope, then choose Confirm action only when the collection is correct. Confirmation queues the same payout-document ZIP batch used by Download Tax Documents in the payout list; it does not wait for file generation inside the chat.

After a successful confirmation, the card shows the batch job UUID and a link to the payout jobs list. Open that page, find the matching UUID, wait until the batch finishes, then open its three-dot menu and choose Download. Do not repeat the action merely because the ZIP is still queued. The chat does not file taxes, calculate a return, or generate an accounting earnings report; requests for those outcomes must still be declined without inventing another proposal.

A ticket outside systems and integrations needs one authorized operation or reservation. You can provide the ordinary apartment, accommodation, or listing name: the agent first searches it as an operation and uses the identifier returned by Holidario. You do not need to know an internal ID. If several results match, the agent must show them for selection; if none match, it asks for a more distinctive name or reservation reference.

Once the mandatory context is available, the provider must immediately call the tool, which creates a proposal, not the effect. You do not need to confirm that you want a preview first. If the provider describes a proposal or card that it did not actually request from Holidario, the server discards that text and retries the turn once with an explicit instruction to use the tool. Only a server-issued card proves that the proposal exists:

1. review the action type, resource, recipient, or before-and-after difference;
2. correct the request in another message if the preview is wrong;
3. confirm only the exact proposal with Confirm action on its card; when exactly one proposal is pending, you may also type “I confirm”;
4. verify the linked result.

An ordinary “OK” or “yes” does not execute an action. The card is authoritative: before confirmation it says that the action has not run, and it changes to completed only after a successful server response. If assistant prose contradicts that state, trust the card and linked result. Holidario reuses an identical pending proposal instead of creating duplicates when the conversation continues.

Proposals expire. On confirmation, Holidario reloads the resource and rechecks user, tenant, permission, business rules, and concurrent changes. Confirmation expresses consent but never adds permission. An executed proposal has an idempotency key and does not run again if confirmation is repeated.

The first side-effect actions are:

• Request an owner calendar blockage: available only to a user who can read and is authorized for the managed operation but cannot edit its rental calendar directly. The agent resolves the accommodation, asks for the first blocked night and the checkout/unblock date, checks the calendar, then asks for a mandatory reason. The end date is exclusive: a request from July 20 to July 23 covers the nights of July 20, 21, and 22, and releases July 23. The server checks availability when preparing the card and again on confirmation. Confirmation creates only a pending BlockedDatesRequest for agency review—it never creates a reservation, event, channel block, or confirmed calendar blockage. The agency's later approval remains a separate workflow and performs another availability check.
• Create a ticket: uses the authenticated user as creator, infers category and priority from the request, and requires a related operation or reservation except for systems and integrations. Because Holidario requires an assignee, the card includes a required searchable selector. Opening it loads the first authorized choices from Holidario; typing a name performs another server search, so the card does not download the tenant's complete staff list. Results contain only people the current user may choose for that ticket category. Select the assignee on the card before confirming. The provider receives neither the search, names, list, IDs, nor selected value. The authenticated browser receives each display label with a short-lived opaque option token bound to the proposal, chat, tenant, user, action version, field, and expiry. On confirmation Holidario decrypts that token, resolves the real ID only on its server, and rechecks that the assignee is still allowed. The agent therefore neither chooses a person nor automatically assigns the first available member. A proposal created with an older confirmation format cannot be confirmed; request a fresh proposal.
• Send support email: the recipient is always [email protected]; the model cannot supply sender or recipient.
• Update an operation's internal description: replaces only private notes on an authorized short-term-rental operation. It does not change the name or guest-visible notes and fails if content changed after preview.

Errors and recovery#

• Agent button is missing: check that the user has a current tenant, the plan, tenant enablement, the OpenRouter key, and a compatible model saved for this agent. There is no separate chat permission to assign.
• OpenRouter rejects the API key: open Edit, replace the invalid, expired, or revoked key with an active OpenRouter API key, reaccept the attestation, and save. The key is never shown in the browser and must not be sent to support.
• Provider unavailable: validate the OpenRouter key, model, credits, limits, and quota from settings.
• The Taxes & earnings accommodation selector does not load: retry without leaving the step. If it still fails, keep All accommodations to build the date-range request without that filter; also check read-operation, read-short-term-rental-operation, the active tenant, and operation authorization. If the prompt appears in the conversation but no result follows, investigate the normal provider/tool trace as well as Holidario validation, permission, and lookup behavior.
• FAQ not found: check that it is active, translated, and authorized for the user.
• Documentation not found: use title or category terms, check that public documentation is enabled, and confirm that the page belongs to the user's documentation audience. A page intended for another role behaves as nonexistent to the agent.
• Accommodation not found: use a distinctive part of the short-term-rental operation name or its ID, and check that you retain read permission and authorization for that resource.
• Reservation not found: use the guest's full name or paste the complete Booking.com, Airbnb, or Holidario reference; check the current tenant, read-reservation, your authorization for the reservation, and normal visibility filters.
• No capability appears after finding a resource: make sure there is exactly one match and that the action remains enabled for the current tenant, plan, role, permissions, and record. Recent references expire after 60 minutes; find the resource again after expiry.
• The reservation link cannot be prepared: find the reservation again and check that it is not cancelled, has a check-out date, and you retain access to both the reservation and event. A past check-out should produce the anonymized historical-view card, not an authorization error. Do not try to reconstruct an earlier URL.
• Another resource was not found: use its ID or an identifier from the table above, then check read permission, plan feature, tenant, and record authorization. For payouts, provide an exact range, a whole year, or a month and year; for accommodation expenses, provide a whole year or month and year; for other periods, provide month and year. Payouts use the creation date shown in the list, while accommodation expenses use their own expense date.
• The exact request cannot be performed through the chat: the agent should say so without attributing it to a permission, plan, or setting that it has not established. Choose an offered alternative only when it matches your goal; suggestions come from the actions and resource capabilities available to the current user.
• The search asks for another detail: answer only the specific question. A whole-year payout or accommodation-expense request that already includes the year needs no further detail and should run immediately. For a ticket or cleaning task supplied with only a year, provide the month; the agent should retain the year and search one calendar month.
• The payout range is not submitted: complete From and Through with valid dates. Both are included in the search, and Through cannot precede From.
• The response says it is searching but shows no result: no background task exists. Holidario automatically discards that text and asks the provider once to execute the lookup. If the final lookup-not-executed message appears, repeat the complete request; if it happens again, ask an administrator to inspect the application logs without sending customer data or the API key.
• A payout question does not show a financial card: Holidario discards an answer that mentions a card without executing the lookup and asks the model once to use the correct capability. If the final message says the lookup was not executed, ask for that detail again about the current payout, or find the payout again when several recent references exist. Check read-p-m-s-payout, the payout feature, and record authorization. If totals appear but accommodation-expense descriptions do not, also check read-property-expense and authorization for those expenses. Do not treat an amount previously written by the assistant as evidence.
• Owner blockage dates are unavailable: choose another range. The availability tool returns only available or unavailable and never exposes the conflicting reservation or event.
• Owner blockage proposal is rejected on confirmation: the calendar, operation, authorization, or action setting changed after the preview. No request, reservation, or event was created; check the current dates and prepare a new proposal.
• Owner blockage request is pending: do not treat the dates as blocked yet. Wait for the agency to review it; only the later approval workflow can create the actual calendar blockage.
• The proposal could not be prepared and no card appears: Holidario already discarded an unsupported claim and asked the provider once to use the correct tool. If the resulting message says that no proposal exists, request the action again. Reopening the chat restores only proposals that the server actually created; without a card there is nothing to confirm.
• The prose says the action finished but its card is still pending: the action did not execute. Confirm through the card, or type “I confirm” when exactly one proposal is pending, then verify the completed state and result link.
• Reply already in progress: wait for the current answer to finish before sending another message in that chat; concurrent tabs cannot start overlapping provider runs for the same session.
• The tab closed during a reply: reopen the chat. If the run exceeded its safety timeout without finishing, Holidario shows it as failed and permits a new message; it does not resume an abandoned request or execute an action automatically.
• Budget or rate limit reached: wait for the stated period or ask an administrator to review limits; do not keep retrying.
• Proposal expired: request a new proposal for a current preview.
• Permission revoked or resource changed: do not force execution; review access and prepare again from current state.
• Provider error: the chat does not treat failure as a completed action. Check before repeating an operation that could have an effect.
• Internal agent error: retry once. If it repeats, do not change or rotate the key solely because of this message; ask a Holidario administrator to review the application logs.

Do not send API keys, passwords, identity documents, or secrets in chat. For a repeated error, email [email protected] with tenant, provider, model, time, time zone, attempted action, and visible message, but never the API key.