Reference · built on requestConnectorWork & ticket management

Freshservice

Tickets, problems, changes, releases, assets, and approvals from Freshservice accounts through the Freshservice API v2.

Request accessPricing ↗

About

Freshservice is Freshworks' IT service management product. An account holds tickets, which are incidents or service requests, along with problems, changes, releases, assets, contracts, agents, requesters, and a service catalog. The API v2 answers at https://domain.freshservice.com/api/v2/ and returns JSON with rate limit headers on every response.

Through Fibric, an operator reads tickets by filter, watches changes and their approval status, and proposes a reply, a private note, a status or priority change, or a new ticket. Every write waits for a person to approve it and is recorded with enough detail to undo.

This is a reference listing. It documents what Fibric would read from Freshservice 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 /api/v2/tickets with filters such as new_and_my_open, requester_id, updated_since, type Incident or Service Request, and workspace_id
  • Filtered tickets through GET /api/v2/tickets/filter?query= with clauses such as priority: 3 AND status: 2, combined with AND or OR
  • Ticket fields through GET /api/v2/ticket_fields, including the custom fields usable in filter queries
  • Problems, changes, and releases through GET /api/v2/problems, /api/v2/changes, and /api/v2/releases, with a change's status, risk, and approval_status
  • Assets through GET /api/v2/assets, with search by name and filters on asset fields
  • Approvals on a service request, with reminders and cancellation
  • Time entries on a ticket, and ticket activity

Proposed actions

  • Target capability: propose a reply to the requester through POST /api/v2/tickets/{id}/reply
  • Target capability: propose a private note through POST /api/v2/tickets/{id}/notes
  • Target capability: propose a status, priority, group, or agent change through PUT /api/v2/tickets/{id}, using status values 2 Open to 5 Closed
  • Target capability: propose a new ticket or child ticket through POST /api/v2/tickets
  • Target capability: propose updating a change record's status or planned dates through PUT /api/v2/changes/{id}

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

What you can build

  • Route a new incident to the right group

    On each poll the operator reads new tickets, their fields, and the requester's department and proposes group_id, priority, and agent for your approval.

    With Ticket Triage, Request Routing

  • Act before a ticket breaches

    The operator reads open tickets by priority and status through the filter query and proposes an internal note to the assigned agent while time remains.

    With Breach Watch

  • Keep changes inside the window

    The operator reads changes with their planned_start_date, planned_end_date, and approval_status and proposes holding any change that lands in a declared freeze.

    With Change Freeze, Patch Window

  • Sweep the backlog

    The operator lists tickets with status Pending past a set age and proposes a reply asking the requester whether the issue stands, or a close.

    With Backlog Sweep

Requirements

  • A Freshservice account and the API key from an agent's Profile settings page
  • An agent whose role can see and edit the tickets, changes, and assets involved; API calls carry that agent's permissions
  • The account's plan, which sets the per-minute limits: Starter, Growth, Pro, or Enterprise
  • For Freshservice for MSPs, the workspace_id of each client, since contacts, locations, and departments are per client
Authentication
Basic access authorization with an agent's API key as the username and any string as the password; each endpoint also lists an OAuth 2.0 scope such as freshservice.tickets.view or freshservice.tickets.create.

Limits

  • Per-minute limits are 100 on Starter, 200 on Growth, 400 on Pro, and 500 on Enterprise, with sublimits per operation
  • List Tickets returns only tickets created in the past 30 days unless updated_since is set; pages hold at most 100 objects
  • Embedding resources with include costs extra API credits; embedding stats consumes three credits in total
  • The API reference documents no outbound webhooks, so changes are read by polling with updated_since

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

Questions and answers

Does Freshservice send webhooks when a ticket changes?
The API v2 reference documents no webhook or event subscription endpoint. The connector polls GET /api/v2/tickets with updated_since, and GET /api/v2/tickets/filter for narrower sets. The same pattern serves problems, changes, releases, and assets.
How does the ticket filter query work?
GET /api/v2/tickets/filter?query= takes a URL-encoded expression such as priority: 1 AND status: 2 OR urgency: 3. Field names are snake case from the Ticket Fields endpoint and are case sensitive. Strings and dates go in single quotes; numbers do not. Custom ticket fields can be used.
What are the rate limits?
Per minute, per account, by plan: 100 on Starter, 200 on Growth, 400 on Pro, 500 on Enterprise, with sublimits for listing, viewing, creating, and updating tickets. Responses carry X-RateLimit-Total, X-RateLimit-Remaining, and X-RateLimit-Used-CurrentRequest; a 429 carries Retry-After in seconds. Paid add-ons raise the limits.
Ask about Freshservice

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 Freshservice 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