Skip to content
Relnivo

Integrations

We connect the tools you already run

Categories rather than a logo wall. What is actually connectable depends on your specific tools and plan tier, and that is established during discovery — before anything is promised.

Note:

Why there are no vendor logos here

A grid of logos implies partnership, certification, or endorsement, and we have none of those. What we have is the ability to integrate with tools that expose a documented API or a supported connector. The categories below describe what we connect and what that connection typically does; whether your particular tool qualifies is a question we answer during discovery, by checking, rather than in advance by guessing.

  • Messaging platforms

    The channels customers actually message businesses on. Automation capability varies by platform and is subject to each platform's own rules.

    What this typically covers

    • Receiving and replying to customer messages
    • Business-account connection with admin permission
    • Template or session-message rules where the platform enforces them
    • Conversation history written to the customer record
  • Telephony and voice

    Phone infrastructure for voice agents, including how calls are routed when nobody answers.

    What this typically covers

    • Conditional routing on busy, no-answer, or out-of-hours
    • Inbound call handling by a voice agent
    • Call recording and transcription, subject to your legal obligations
    • Transfer to a human line under defined conditions
  • Calendars and booking

    Reading real availability and writing real bookings — the difference between an agent that books and one that promises someone will call.

    What this typically covers

    • Reading availability across staff or resources
    • Creating, rescheduling, and cancelling appointments
    • Buffer, duration, and working-hours rules
    • Confirmation and reminder triggers from booking events
  • CRM and sales tools

    Where customer records and pipeline live. We work with what you have where we can.

    What this typically covers

    • Creating and matching contacts and companies
    • Creating opportunities and moving stages on events
    • Writing activity, notes, and transcripts to records
    • Two-way sync where both systems support it
  • E-commerce platforms

    Product, stock, and order data, so an agent answers from reality.

    What this typically covers

    • Reading product details, variants, and stock levels
    • Looking up order status for a customer enquiry
    • Restock and back-in-stock notification triggers
    • Abandoned-enquiry follow-up
  • Websites and forms

    The touchpoints we build, and the ones you already have, feeding the same capture layer.

    What this typically covers

    • Enquiry, booking, and quote-request forms
    • Website chat placement and behaviour
    • Source and campaign tracking carried into the record
    • Multilingual routing based on the visitor's language
  • Email

    Still where a large share of business enquiries arrive.

    What this typically covers

    • Reading a shared enquiry mailbox
    • Sending confirmations, reminders, and follow-ups
    • Threading replies onto the right customer record
    • Deliverability setup for outbound sending
  • Spreadsheets and databases

    A legitimate destination, and often the right one to start with. Not every business needs a CRM on day one.

    What this typically covers

    • Writing structured enquiry records to a sheet
    • Reading reference data such as price lists or service areas
    • Scheduled exports for reporting
    • A migration path to a CRM later, without losing the history
  • Custom and internal systems

    Where no connector exists. This is also where we are most likely to tell you something is not feasible.

    What this typically covers

    • Connections built against a documented API
    • Webhook receivers for systems that can push events
    • Scheduled file or database exchange where no API exists
    • An honest assessment when a system cannot be integrated at all

How we approach it

Four rules we apply to every integration

Integrations are where automation projects usually fail, and almost always for the same reasons.

  • Feasibility is checked, not assumed

    Before a system is included in a scope, we confirm the API exists, the plan tier includes it, and the operations we need are actually available.

  • Credentials stay yours

    Connections are made with credentials issued from your own accounts. Nothing is created under a Relnivo account, and access can be revoked by you at any time.

  • One system is authoritative

    For every synced field we decide, in writing, which system wins when the two disagree. Skipping this is how data quietly corrupts.

  • Failures alert

    A sync that fails retries, and then tells someone. An integration that fails silently is worse than none, because everyone assumes it is working.