Native integration
Published only after a supported, maintained connector is verified.
Home / Integrations
Truthful integration status
Connect Claire to the systems the workflow actually uses.
Claire’s API Call, variables, branching and workflow actions support configurable connections. A system name never means a native integration unless Claire has verified and published that status.
RequestUnderstand the person, context and desired outcome
CoordinateApply rules, maintain state and involve the right systems
ActExecute only permitted actions and communications
GovernEscalate exceptions and preserve human control
Truthful integration status
Built for operational depth.
Claire can be configured to work around authorized systems and APIs. Integration status is validated during implementation.
API integration
A supported API connection built for an agreed workflow.
Configurable integration
Connection feasibility depends on API access, credentials and implementation scope.
Planned / unavailable
Named plainly when a requested connection is not currently supported.
Credential boundaries
Secrets belong in controlled credential storage, not page content or prompts.
Human fallback
Unavailable actions route context to a person rather than pretending completion.
Human control
Automation with explicit boundaries.
Decide where Claire executes, where a person approves, and which exceptions require takeover.
Claire coordinates
Configured retrieval, preparation, communication and actions.
People remain accountable
Judgment, approval, relationships and consequential decisions.
Connection design
An integration is an operational contract, not a logo.
Before Claire reads or writes anything, implementation must establish what the target system permits, which records matter, how identity is matched, what happens when the system is unavailable and which action requires a person.
1. Define the job
Name the exact read or write: retrieve a customer, check a schedule, create a work order, update a load, attach a document or record an outcome.
2. Verify access
Confirm the customer’s edition, API availability, authentication method, scopes, rate limits and any vendor approval process. A public API does not guarantee customer access.
3. Map identity and fields
Decide how callers, contacts, accounts, properties, loads, claims and assets are matched—and which fields are required before an action is valid.
4. Bound the action
Limit each connection to the records and operations the workflow needs. Consequential or ambiguous actions can route to a human with context instead.
5. Design failure behavior
Handle timeouts, missing records, duplicate matches, validation errors and unavailable systems explicitly. Never tell the customer the work is complete when the write failed.
6. Validate end to end
Test the conversation, data mapping, system result, outbound confirmation and exception path together using approved non-sensitive test data.
Status language
What our integration pages mean.
The current named-system pages describe possible configurable API workflows. They do not assert a native connector, marketplace listing, vendor partnership, certification or existing customer deployment.
Bring these facts to discovery
- System name, edition and account owner
- The exact workflow and fields involved
- Available API or webhook documentation
- Authentication and permission constraints
- Expected volume, latency and failure handling
Show us the workflow.
Bring the request, systems, policies and handoff points.
Integration buying questions
Ask what the workflow must read, write, wait for, and recover from.
The most commercially useful integration is not always the best-known system. It is the connection that unlocks several high-value workflows for the customers Claire is positioned to serve. Prioritization should consider customer penetration, available access, implementation feasibility, workflows unlocked, exception behavior, and revenue leverage.
Read requirements
Which identity, customer, job, appointment, load, unit, policy, claim, inventory, or ticket must Claire retrieve—and how is the correct record matched?
Write requirements
Must Claire create, update, attach, schedule, cancel, dispatch, or record an outcome? Which writes require validation or approval?
Async requirements
Does the workflow wait for a webhook, human decision, vendor acknowledgement, carrier event, document, or scheduled time before resuming?
Recovery requirements
What happens on timeout, rate limit, duplicate match, validation error, partial completion, unavailable system, or revoked credential?
Every published integration page states the connection status precisely: native, API-capable, configurable, or not currently available. A vendor name alone is not evidence that Claire can access a customer’s edition or perform a particular write.
The connected-system demonstration should show more than a logo: the object retrieved, proposed or completed action, permission boundary, response, error path, and system of record. Where live access is unavailable, label the screen as a workflow example and explain that customer-specific integration validation is required.