Connect a CRM, ERP or HIS

Iris connects to specific operations you approve, not an entire database just because you name its software. Your CRM, ERP, HIS or custom backend needs a compatible API, webhook or MCP tool. In this guide, HIS means hospital information system.

These are generic integration options, not a catalogue of prebuilt or certified vendor connectors. Check your vendor's API availability, account permissions and supported authentication before promising a feature. The examples below describe endpoints your team could provide; they are not Flowlith endpoints or services already installed in your account.

Choose the connection your backend can support

A gateway is not a way around your provider's authorization, permissions or usage restrictions. Iris does not install it, open a VPN, read arbitrary SQL tables or automatically implement vendor protocols. There is no built-in HL7/FHIR connector implied by the HIS examples.

Keep these directions separate:

Owner's AI app → Flowlith MCP → configure and approve an Action
Customer → Iris → approved Action → your API / MCP tool → business system
Website browser → your backend → Flowlith Website API → Iris

The Website API sends messages to Iris. It does not expose your CRM to Iris. Actions are how Iris calls your system.

Give your developer this readiness checklist

OpenAPI/Swagger JSON or YAML can help describe operations. It is not required if you supply accurate request/response examples. API documentation does not itself authorize access or activate an Action.

Create a narrowly scoped integration credential. Enter it only through get_key_link or the dashboard's dedicated key-entry form. Mark credential headers as secret. Do not put credentials in URLs, plain constants, source code, chat, screenshots or the handoff document. Flowlith's owner-connector sign-in does not sign Iris into your other systems.

The connection fixes the destination host and base path. For https://api.example.com/iris, use paths such as /stock/{sku}; a customer input must never choose a different server. Your normal API access checks still apply.

Map a real operation, not a product name

All examples are conditional on your backend implementing and authorizing the operation.

An Action that submits a request is not the same as one that completes it. “Appointment requested” must not become “Appointment booked”; “return requested” must not become “refund paid”. Return a status the customer can understand.

Authenticate the system and authorize the customer separately

The integration key identifies your business integration. It does not prove that a customer may see a particular CRM contact, order, invoice or patient record.

Use platform-supplied channel/customer identity where appropriate, mapped as a system field, not a customer-editable input. Your backend must still establish the relationship between that identity and its own account or record. A WhatsApp phone, channel ID, typed name, date of birth or order reference alone is not a general identity-verification or patient-authorization process.

For private operations, require your normal secure verification/linking flow, then check the authenticated tenant, linked customer, record ownership, scope and permitted operation on every request. A secure portal or human-assisted verification may be required. Do not ask for passwords or login codes in the conversation; do not put a session token into an Action's customer-input field.

Configure Bind result to this customer when appropriate and return the ownership value at that configured path. This is an additional result check, not a replacement for backend authorization. Never just echo the supplied customer identifier next to an unrelated record. A prompt saying “only return their own records” is not an access-control implementation.

Read example: a public stock summary

Assume a business allows customers to see this stock summary. Authentication is configured privately and omitted from the example. Your server exposes:

GET /iris/stock/MUG-001 HTTP/1.1
Host: api.example.com

Return 200 OK with Content-Type: application/json:

{
  "sku": "MUG-001",
  "available": true,
  "stock_status": "in_stock",
  "checked_at": "2026-11-07T09:00:00Z"
}

Configure a required bounded sku input into the path and select those four response fields. Do not send supplier costs, warehouse credentials or a full inventory export. An order-status variant needs customer authorization; do not copy this public-data assumption to private records.

Write example: create a CRM service request

This illustrative endpoint creates a request for review. It does not book an appointment, issue an invoice or complete the requested service. The backend must authenticate the integration, authorize the linked customer and validate the category before committing anything.

Connection configuration

Save the credential separately. The example connection ID/version in the next block must be replaced with the real saved connection values.

{
  "name": "Business service API",
  "kind": "api",
  "base_url": "https://api.example.com/iris",
  "auth": { "kind": "bearer" },
  "headers": []
}

Write-action mapping

This is the Action's configuration, not a request body for your CRM. It maps customer inputs and trusted conversation identity into your API's own JSON shape. Mark it changes data and complete owner Preview, Test and activation before customer use. Use the Actions guide for the surrounding draft workflow.

{
  "mode": "direct",
  "connection_id": "11111111-1111-4111-8111-111111111111",
  "connection_version": 2,
  "method": "POST",
  "input_schema": {
    "type": "object",
    "additionalProperties": false,
    "properties": {
      "category": { "type": "string", "maxLength": 16, "enum": ["sales", "support"] },
      "summary": { "type": "string", "maxLength": 300 }
    },
    "required": ["category", "summary"]
  },
  "fixed_fields": {},
  "system_fields": { "channel": "channel", "customer": "customer_channel_id" },
  "requires_confirmation": true,
  "bind_customer_path": "customer_channel_id",
  "link_hosts": [],
  "timeout_ms": 10000,
  "idempotent_retry": false,
  "direct": {
    "path": "/service-requests",
    "body_type": "json",
    "sign": false,
    "idempotency_header": "Idempotency-Key",
    "placements": [
      { "source": "input", "field": "category", "in": "body", "target": "/category" },
      { "source": "input", "field": "summary", "in": "body", "target": "/summary" },
      { "source": "system", "field": "channel", "in": "body", "target": "/customer/channel" },
      { "source": "system", "field": "customer", "in": "body", "target": "/customer/id" }
    ]
  }
}

For a fictional verified website customer, after a later customer message confirms the exact proposed request, the resulting body is:

{
  "category": "support",
  "summary": "Please help arrange a product demonstration.",
  "customer": { "channel": "http", "id": "demo-customer-42" }
}

Iris sends POST https://api.example.com/iris/service-requests, the privately configured authentication, Content-Type: application/json and an opaque operation value in Idempotency-Key. There is no extra Iris envelope. Your backend must map the channel identity to an authorized customer; this example does not implement that mapping for you.

Return 201 Created with Content-Type: application/json only after the request is committed:

{
  "request_id": "DEMO-REQ-1042",
  "status": "awaiting_review",
  "customer_channel_id": "demo-customer-42",
  "message": "Your service request was received for review."
}

Select request_id, status and message for Iris's answer. Keep the ownership field available for the configured binding check, not as a customer-facing message. The sample identity format is for website chat; validate the correct channel-specific ownership value when adapting it to WhatsApp or another channel.

Keep the backend contract small and explicit

• Action inputs support up to 12 flat fields: bounded strings (up to 500 characters), bounded numbers/integers, booleans, or arrays of bounded strings (up to 20 items). They are not arbitrary nested JSON Schema. Direct field mappings can construct nested JSON for your API.
• Direct API operations use GET, POST, PUT, PATCH or DELETE, with no body, JSON or form encoding as appropriate. GET has no body. File uploads, raw database queries and arbitrary binary protocols are not covered by this connection.
• Keep a direct request body within 16,000 bytes. Return within the configured timeout, at most 10 seconds. Decoded responses are limited to 64 KiB, and Iris receives a smaller selected result. Return short summaries and bounded search results; paginate or aggregate in your backend.
• For structured success, return UTF-8 application/json. Plain text is also supported, but it cannot provide structured customer-binding fields. Do not return HTML login pages, PDFs, vendor-specific JSON content types or an empty 204 response as the only success proof.
• Use explicit HTTP errors for rejected requests and safe, short explanations. Never put tokens, stack traces, full records or connection strings into errors. A successful HTTP status is not proof that the requested business effect completed.
• If work must continue asynchronously, return a job reference and truthful queued/pending status quickly, then provide a separate read-only status Action. Iris does not automatically keep polling or push a later notification just because your API returned 202.

Your API must enforce idempotency: atomically bind the operation key to the authorized tenant/customer, exact payload and saved result alongside the business change. A repeated key must not create a second record; a changed payload must not silently reuse it. The header alone does not deduplicate anything.

Iris does not automatically repeat a sent direct API/MCP write, even after a timeout or an error. Unknown is not failed. Keep a safe reference for reconciliation, inspect the system or use an approved read-only status operation, and do not ask the customer to resend the same write as a new request to force success.

Additional boundary for a hospital system

Start with public information or a limited administrative workflow. Patient-specific scheduling, proxy requests and record access need the hospital's approved verification, authorization, privacy and operational review before connection. No example here establishes healthcare compliance or suitability for clinical use.

Do not send full patient charts, diagnoses, prescriptions, laboratory reports or unnecessary identifiers when a task needs only an availability result or request status. Do not place patient data into shared business Info, Memory, assets or skills. Keep the system of record responsible for access decisions, audit records, scheduling rules and the real outcome.

This guide does not configure diagnosis, triage, treatment recommendations or autonomous clinical decisions. If the intended task requires clinical judgment or protected-record access that has not been approved, keep it outside the integration and use the hospital's existing staff/portal workflow.

Acceptance tests before enabling customers

Owner Test is a real request, not an automatic dry run. Use fictional records and a test account. Verify the downstream record yourself. Only turn on the exact reviewed version after a successful Test and explicit approval. Test every intended channel because identity and available customer fields differ.

Copy a non-secret handoff to your backend team

System: [CRM / ERP / HIS / custom backend and version]
Owner and tenant/branch: [who authorizes this connection]
First customer journey: [one read or one confirmed write]
Public API docs or redacted examples: [link / attachment]
Final HTTPS base URL or token MCP endpoint: [URL without credentials]
Authentication type: [type only; enter the key through the secure link]
Required inputs and rules: [fields, bounds, enums, units, timezone]
Customer authorization: [existing verified account-linking/ownership flow]
Response fields and real completion state: [minimal useful result]
Idempotency and status lookup: [how duplicate/unknown writes are handled]
Test account and fictional records: [non-secret references]
Support owner: [role/contact approved for sharing]
Do not include tokens, passwords, customer records or patient details.

Next: MCP connections · Configure Actions · What Iris can do.