Reference · built on requestConnectorSupport & service desks

Trengo

Tickets, messages, contacts, and channel events from Trengo's multichannel inbox through REST API v2 and signed webhooks.

Request accessPricing ↗

About

Trengo is a multichannel inbox. Tickets arrive from email, WhatsApp, voice, and other channels, each with a status of OPEN, ASSIGNED, CLOSED, or INVALID, a contact, a channel, an assigned user or team, and labels. The API is served at app.trengo.com/api/v2, and webhooks fire on messages, ticket changes, voice calls, WhatsApp delivery, and contact changes.

Through Fibric, an operator reads tickets and messages as webhooks deliver them, checks the contact's last interaction, and proposes a reply, an internal note, an assignment to a user or team, or a closure with a ticket result for your approval. Calls stay under the per-minute limit. Every approved action is applied a single time and written down with its reason and the step that reverses it.

This is a reference listing. It documents what Fibric would read from Trengo 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

  • Tickets through GET /tickets, filtered by status, contact_id, users[], channels[], labels[], last_message_type, and updated_at_gt
  • Ticket fields including subject, user_id, contact_id, assigned_at, closed_at, custom_data, channel, and latest_message
  • Messages on a ticket, and the full content of an email message
  • Contacts through GET /contacts, searched by term across email, phone number, and name, with lastInteraction on request
  • Webhook events INBOUND, OUTBOUND, NOTE, TICKET_CREATED, TICKET_ASSIGNED, TICKET_CLOSED, TICKET_REOPENED, TICKET_MERGED, and label changes
  • Voice events VOICE_CALL_STARTED, VOICE_CALL_ENDED, VOICE_CALL_RECORDED, and VOICE_CALL_MISSED, with direction and duration
  • WHATSAPP_MESSAGE_DELIVERY_FAILED, WHATSAPP_MESSAGE_READ, and FIRST_HUMAN_REPLY_TIME_CALCULATED

Proposed actions

  • Target capability: propose a reply or an internal note through POST /tickets/{ticket_id}/messages
  • Target capability: propose an assignment to a user or a team, with a note, through POST /tickets/{ticket_id}/assign
  • Target capability: propose closing a ticket with an optional ticket_result_id through POST /tickets/{ticket_id}/close

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

What you can build

  • Summarize a call

    When VOICE_CALL_ENDED or VOICE_CALL_RECORDED fires, the operator reads the ticket and contact and proposes an internal note with the call's direction, duration, and what was agreed.

    With Call Summary

  • Route a new ticket

    On TICKET_CREATED, the operator reads the first message and the contact's last interaction and proposes an assignment to a user or team with a note.

    With Ticket Triage

  • Catch a reopened ticket

    When TICKET_REOPENED fires, the operator reads what arrived and proposes an assignment back to the user who last handled it, with a note.

    With Reopen Guard

  • Watch the first human reply

    The operator reads FIRST_HUMAN_REPLY_TIME_CALCULATED events and open tickets whose latest_message is INBOUND, and proposes an assignee for those waiting longest.

    With First Response

Requirements

  • A Trengo account and a personal access token for its API v2
  • A webhook created under Settings > Apps & Integrations > Webhooks, or through the API, subscribed to the events you need
  • An HTTPS endpoint that checks the Trengo-Signature header against your signing secret
  • Channels connected in Trengo for the email, WhatsApp, or voice traffic the operator should read
Authentication
A personal access token from your Trengo account, sent as a bearer token in the Authorization header with Content-Type and Accept set to application/json.

Limits

  • 120 requests per minute; every response carries x-ratelimit-limit and x-ratelimit-remaining, and a 429 carries Retry-After and X-RateLimit-Reset
  • Subject and attachment_ids on a ticket message apply only to email; the subject is prepended with Re: on a reply
  • Webhook payloads differ by event, and some carry nested form fields such as referral[source_type]
  • The webhook guides describe signature checks but not delivery retries

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

Questions and answers

How does Trengo sign webhook requests?
Each request carries a Trengo-Signature header holding a timestamp and a hash separated by a semicolon. The hash is a lowercase hexadecimal SHA256 HMAC of the timestamp, a period, and the request body, keyed with your signing secret. You recompute it and compare.
What rate limit applies to the Trengo API?
120 requests per minute. Responses include x-ratelimit-limit and x-ratelimit-remaining. Over the limit, Trengo returns 429 Too Many Requests with Retry-After and X-RateLimit-Reset headers.
Can a ticket be closed with a reason?
Yes. POST /tickets/{ticket_id}/close accepts an optional ticket_result_id that applies a ticket result. Assignment goes through POST /tickets/{ticket_id}/assign with a type of user or team, the matching id, and an optional note.
Ask about Trengo

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Trengo through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy