A new lead starts an agreed task
This example shows the module’s role in a hotel process. We define the source scope and available actions for each implementation.
A sales representative adds a company to the CRM
The team wants to receive a profile of a prospective customer without entering the company name again in a separate tool.
An organised result in the sales process
The CRM calls the connected research module through the API. It receives a result or a task ID for retrieval later. Saving the result in the CRM requires a separately configured integration and does not automatically start contact with the company.
- Explicit data format
- Operation status and ID
- Result and failure handling
What does this module cover?
We design specific operations, not unlimited access to the implementation’s inner workings. We define formats, authentication, limits, timeouts and behaviour when a request is retried. Long-running tasks can run asynchronously.
System-accessible features
Another application can start an agreed task and retrieve its result.
Controlled data contract
It is clear which fields are required and how the system signals missing data or an error.
Traceable operations
A call history makes it easier to identify duplicates and explain problems.
How do we launch the solution?
Defining the operation
We select the features, recipients and minimum data needed for the task.
Securing the interface
We assign permission scopes, limits and access-management rules.
Testing the integration
We check successful results, missing responses, invalid data and safe retries.
What goes into the module and what comes out?
We separate source material from the tool’s output. This helps subsequent modules understand which context they can use.
What does AI use?
- Authenticated request
- Defined parameters
- Available task-execution module
What does the team receive?
- Structured result or task status
- Error information
- Call log
Permissions and decisions remain with the hotel
Before launch, we agree data access, responsible people and how exceptions will be handled.
Access is granted separately to each application. Read and write operations have separate permissions; keys and sensitive data are not placed in public website code.
The API itself does not add a feature that the implementation does not already have. Nor is it an automatic connector to any PMS or CRM.
What changes in day-to-day work?
Systems can pass data between them without a staff member being involved at every step.
Each task has a result or a clear status instead of failing silently.
Which sources and tools do we connect the module to?
The scope depends on the implementation’s features and the capabilities of the calling system. We document the interface and test error scenarios before launch.
Related process elements
Its place in the implementation journey
These links come from the roadmap. Requirements form the basis of each node, while enrichments extend its capabilities. This does not mean that all subsequent modules must be launched at once.
Modules this element enriches
Frequently asked questions
Does the API replace CRM integration?
No. The API makes a feature available, while the integration determines when the CRM calls it and where it saves the result.
What if the task takes longer?
We can return an ID and status, then provide the result later. We agree how to poll for updates or send notifications as part of the integration contract.