Reference · built on requestConnectorSupport & service desks

Richpanel

Conversations, comments, customers, and synced orders and subscriptions from a Richpanel help desk.

About

Richpanel is a help desk for online stores. It keeps conversations, customers, agents, teams, tags, and channels, and it holds a copy of each store's orders and subscriptions so agents see purchase history beside the thread. A conversation carries a status of OPEN, SNOOZED, or CLOSED, a priority, an assignee, tags, comments, a customer profile, and a satisfaction rating. The API is served at https://api.richpanel.com/v1.

Through Fibric, an operator receives HTTP Target posts from your automation rules, reads the conversation and the customer's orders, and proposes a public reply, an internal comment, a status change, or an assignment for your approval. Each approved change is a single PUT on the conversation, recorded with what changed and why.

This is a reference listing. It documents what Fibric would read from Richpanel 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 by conversation number, or by a customer's email or phone through GET /tickets/{type}/{id}
  • Status OPEN, SNOOZED, or CLOSED, priority LOW or HIGH, assignee_id, tags, and via.channel such as email, chat, facebook, instagram, whatsapp, or twilio-sms
  • Comments on a conversation with sender_type and a public flag, plus the customer_profile attached to it
  • Timing fields first_response_duration, resolution_duration, and closed_at, and the satisfaction_rating on a conversation
  • Customers by email or phone, with the orders and subscriptions synced to them
  • HTTP Target posts fired by automation rules when a conversation is created, closed, assigned, or tagged, or when a message arrives

Proposed actions

  • Target capability: propose a reply or an internal comment through PUT /v1/tickets/{id} with a comment body and the public flag
  • Target capability: propose a status change to OPEN or CLOSED, a new assignee_id, or a tag set through PUT /v1/tickets/{id}
  • Target capability: propose an order or subscription record through POST /v1/order/{appclient_id}, which creates or updates by orderId
  • Target capability: propose a customer record update through the Create/Update Customer endpoint

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

What you can build

  • Answer an order question from the synced order

    When a new-message post arrives for a shipping question, the operator reads the customer's orders in Richpanel and proposes a public comment with the order status.

    With WISMO Deflection

  • Send the first reply on a new conversation

    On a conversation-created post the operator reads the channel and the last comment and proposes a public reply for approval.

    With First Response

  • Close conversations the customer has left

    For conversations with no customer comment after the last agent reply, the operator proposes status CLOSED, one PUT per conversation.

    With Backlog Sweep

  • Follow up a low satisfaction rating

    The operator reads satisfaction_rating on closed conversations and proposes a reopened conversation assigned to a named agent.

    With Detractor Callback

Requirements

  • A Richpanel account and an API key from Settings, Integrations, API Keys
  • The appClientId of each store or brand, found under Settings, Connected Apps, for order and subscription writes
  • An HTTP Target under Settings, Integrations, HTTP Target, with an automation rule that fires it on the events you want
Authentication
An API key generated under Settings, Integrations, API Keys in the Richpanel app and sent on every request in the x-richpanel-key header.

Limits

  • The reference documents no endpoint that lists all conversations; reads are by conversation number or by a customer's email or phone
  • HTTP Target posts carry the variables you choose and no signature; the connector checks the header you configure and re-reads the conversation by id
  • No rate limit is published for the API
  • The update body accepts status OPEN or CLOSED, while the conversation object also reports SNOOZED

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 Richpanel ↗

Questions and answers

How does Richpanel authenticate API requests?
With an API key. Generate or view it under Settings, Integrations, API Keys in the Richpanel app and send it in the x-richpanel-key header. Requests go to https://api.richpanel.com/v1.
Does Richpanel send webhooks?
Yes, through HTTP Target. Under Settings, Integrations, HTTP Target you set a URL, choose the variables to send, and add authentication headers. Automation rules fire it when a conversation is created, closed, or assigned, when a tag is added, when a message arrives, or when status or priority changes.
Can the connector see store orders?
Yes, once they are synced. POST /v1/order/{appclient_id} creates or updates an order by orderId with its amount, status, line items, and customer. The conversation's customer_profile then carries that customer's history.
Ask about Richpanel

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.