Reference · built on requestConnectorSupport & service desks

Crisp

Conversations, messages, people profiles, and live session events from a Crisp website through its REST and RTM APIs.

About

Crisp is a messaging platform for websites. Each website has conversations keyed by session_id, messages, people profiles, operators, teams, an inbox, and a helpdesk. Its REST API at https://api.crisp.chat/v1/ reads and writes these, and the RTM API streams every event on the website over a WebSocket. Web Hooks post the same events as JSON to a URL you choose.

Through Fibric, an operator subscribes to session and message events, reads the conversation and the person's profile, and proposes a reply, a state change, or an assignment for your approval. Each approved write goes out once and leaves a record of what changed and how to undo it.

This is a reference listing. It documents what Fibric would read from Crisp and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Conversations for a website through GET /v1/website/{website_id}/conversations/{page_number} and one session through /conversation/{session_id}
  • Messages in a conversation through /conversation/{session_id}/messages, with message:send and message:received events as they happen
  • Conversation state and routing, and session events such as session:set_state, session:set_routing, session:set_segments, and session:sync:rating
  • People profiles through /v1/website/{website_id}/people and /people/{people_id}, with people:profile:created and people:profile:updated events
  • Operators, teams, availability, inbox, and helpdesk resources on the website
  • Web Hook posts carrying website_id, event, data, and a UNIX timestamp in milliseconds

Proposed actions

  • Target capability: propose a message through POST /v1/website/{website_id}/conversation/{session_id}/message
  • Target capability: propose a state change through PATCH /v1/website/{website_id}/conversation/{session_id}/state
  • Target capability: propose an operator assignment through PATCH /v1/website/{website_id}/conversation/{session_id}/routing
  • Target capability: propose a people profile update through PATCH /v1/website/{website_id}/people/{people_id}
  • Target capability: propose a new conversation through POST /v1/website/{website_id}/conversation

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Reply while the visitor is still on the page

    On session:request:initiated and the first message:send, the operator reads the message and the people profile and proposes a reply for approval.

    With First Response

  • Hand a stalled chat to a person

    When a visitor keeps writing with no operator reply, the operator proposes a routing change to an available operator through the routing endpoint.

    With Bot Handoff

  • Route a chat by the visitor's language

    The operator reads session:sync:locales on the session and proposes an assignment to an operator or team for that language.

    With Language Routing

  • Follow up on a poor rating

    session:sync:rating carries the visitor's rating. For a low one the operator proposes a follow-up message and a segment on the profile.

    With Detractor Callback

Requirements

  • A Crisp website and its website_id
  • A Website Token generated in the Crisp app for one workspace, or a Plugin Token from the Crisp Marketplace for several workspaces
  • For a Plugin Token released through the Marketplace, the scopes of the routes the plugin calls, submitted with the plugin
  • A Web Hook endpoint added under the website's Advanced configuration, or a Plugin Hook set in the Marketplace plugin settings
Authentication
HTTP Basic authentication with a token identifier and key, sent with the X-Crisp-Tier header; a Website Token comes from the Crisp app and a Plugin Token from the Crisp Marketplace.

Limits

  • A Website Token is quoted at 10,000 requests per day and a Plugin Token at 5,000 per day by default, which is configurable
  • Requests past the API-wide or per-route limits return 429 Too Many Requests or 420 Enhance Your Calm; Plugin Tokens face a daily Plugin Quota instead
  • Website Hooks are not signed; the guide recommends a key in the URL that your endpoint checks. Plugin Hooks are signed and retried
  • Some Plugin Hook events require manual approval from Crisp

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Crisp ↗

Questions and answers

Which token should the connector use?
A Website Token for one workspace; it is generated in the Crisp app and quoted at 10,000 requests per day. A Plugin Token comes from the Crisp Marketplace, works across workspaces, and carries a configurable daily quota of 5,000 requests by default. Both are sent as HTTP Basic credentials with the X-Crisp-Tier header.
How do events reach the connector?
Two ways. The RTM API streams events such as message:send, session:set_state, and people:profile:updated over a WebSocket. Web Hooks post the same event names as JSON with website_id, event, data, and a timestamp. Website Hooks are set under Advanced configuration; Plugin Hooks are set in the Marketplace.
Are Web Hook payloads signed?
Plugin Hooks are signed and retried on failure. Website Hooks are not signed; Crisp's guide recommends adding a secret key as a URL parameter that your endpoint validates. Website Hooks are available on free and paid plans.
Ask about Crisp

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.