.png)
Freshservice Integration Guide
Freshservice integrates with enterprise systems through REST APIs, selected workflow-driven outbound webhooks, and attachment endpoints.
Freshservice integration options at a glance
Freshservice provides REST APIs for tickets, requesters, agents, departments, changes, problems, releases, assets, service items, and related service-management resources. Its Workflow Automator can send outbound webhook-style requests for selected events and conditions, although coverage is not a universal event stream. Supported ticket operations can also handle attachments through multipart form-data. Martini can consume these APIs, receive configured webhook requests, paginate and throttle large synchronizations, map Freshservice JSON into canonical models, apply routing rules, and expose controlled APIs for applications that need to create or query Freshservice records. API keys with Basic Authentication and OAuth 2.0 are available authentication options.
| Integration point | Supported by Freshservice? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Freshservice REST APIs manage Tickets, Requesters, Agents, Departments, Changes, Problems, Releases, Assets, Service items, and related service-management resources. They support common create, retrieve, update, and delete operations where documented by the resource endpoint. | Martini can consume Freshservice REST APIs from workflows, map JSON payloads, apply business rules, paginate requests, and expose its own APIs for controlled downstream access. |
| Webhooks / outbound callbacks | Limited | Workflow Automator can send outbound webhook-style requests for selected ticket events, conditions, and configured workflow actions. This is not a universal event stream for every Freshservice object or state transition. | Martini can receive the configured requests with a webhook-triggered workflow, validate the payload, enrich it through Freshservice API calls, and route it to downstream systems. |
| Bulk / async / batch APIs | Limited | Freshservice documents pagination, rate limits, and selected bulk operations, but a general-purpose asynchronous bulk API for every resource was not confirmed. | Martini can implement scheduled batch workflows with pagination, checkpoints, throttling, bounded concurrency, and idempotent upserts. |
| File / attachment APIs | Yes | Supported ticket operations can carry file attachments, generally through multipart form-data. Endpoint-specific and plan-specific size or capability restrictions apply. | Martini can retrieve or submit supported attachments, preserve metadata, validate file constraints, and relay files to another API or file destination. |
| Authentication | Yes | Freshservice supports API key authentication using HTTP Basic Authentication and OAuth 2.0 for supported delegated application scenarios. Permissions depend on the agent or authorized application. | Martini can use secured environment configuration and secrets for API keys, Basic Authentication values, OAuth tokens, and endpoint-specific credentials. |
| Scheduled synchronization | Yes | Scheduled retrieval is suitable for incremental synchronization of Freshservice resources using timestamps, filtering, pagination, and high-water marks where supported by an endpoint. | Martini can trigger scheduled workflows, persist checkpoints, apply safety windows, throttle calls, and write normalized results to target applications or databases. |
| Database access | Not confirmed | Freshservice is a hosted SaaS application and direct database access is not part of the documented external integration model. | Martini can consume Freshservice APIs and write the resulting data to supported SQL databases, without requiring direct Freshservice database access. |
| SDKs | Secondary | Freshworks provides developer tooling and SDKs for Freshworks applications, but these are not required for external integrations with Freshservice. | Martini integrations can use the documented REST APIs and webhook requests directly rather than depending on Freshworks application SDKs. |
How Freshservice exposes data and business events
Freshservice REST APIs
Freshservice REST APIs are the primary external integration mechanism for service-management resources, including Tickets, Requesters, Agents, Departments, Changes, Problems, Releases, Assets, and Service items. Operations and available fields depend on the specific endpoint, account configuration, and permissions.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to Freshservice, calls the relevant REST endpoint, handles pagination and response validation, maps the Freshservice JSON payload into a canonical or target model, applies business rules, and writes the result to another application, database, or API.
Implementation sequence
Freshservice outbound webhooks
Freshservice Workflow Automator can send outbound webhook-style requests for selected events, conditions, and configured workflow actions. Coverage must be verified for the particular Ticket event, fields, object, and account configuration; it should not be treated as a universal event stream.
Martini implementation pattern
Martini implementation pattern: expose a controlled webhook-triggered workflow, validate the incoming request, authenticate or otherwise verify the expected source according to the deployment design, enrich the notification with Freshservice REST calls when necessary, and route a normalized event to downstream systems.
Implementation sequence
Freshservice scheduled synchronization
Freshservice list endpoints use pagination, and timestamps or filtering mechanisms can support incremental synchronization depending on the endpoint. Scheduled processing is appropriate for large or reconciliation-oriented data flows where webhook coverage is incomplete.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a workflow that reads a durable high-water mark, retrieves pages of Freshservice data, applies a safety window around updated timestamps, transforms each object, performs idempotent writes, and advances the checkpoint only after successful processing.
Implementation sequence
Freshservice attachment operations
Supported Freshservice ticket operations can handle attachments through multipart form-data. Attachment capabilities, endpoint behavior, and size restrictions should be verified for the specific operation and Freshservice plan.
Martini implementation pattern
Martini implementation pattern: retrieve or receive attachment metadata, validate file type and size, call the Freshservice multipart endpoint or downstream file endpoint, preserve filename and content type, and record whether the destination copied, referenced, or excluded the attachment.
Implementation sequence
Common Freshservice integration patterns
Pattern 1: Synchronize employees and departments
When to use this pattern
Use this pattern when Workday, Microsoft Entra ID, or another identity source owns employee lifecycle data and Freshservice must maintain current Requesters, Agents, and Departments. The flow should distinguish user types and avoid overwriting Freshservice-specific permissions without an explicit rule.
Integration direction
Example Mapping
| Freshservice Field | Canonical Field | Target Field |
|---|---|---|
| worker.id | employeeExternalId | Requester.external_id |
| worker.name | displayName | Requester.name |
| worker.department | departmentName | Department.name |
Martini implementation pattern
A scheduled Martini workflow retrieves changed workers and departments, maps them into separate Freshservice object models, validates lifecycle and ownership rules, and performs idempotent updates. It stores a checkpoint and sends permission, validation, or matching exceptions to an operational queue or review process.
Martini capabilities used
- workflows
- scheduled triggers
- API consumption
- pagination and checkpointing
- data mapping
- business rules
- error handling
Pattern 2: Create Freshservice tickets from business applications
When to use this pattern
Use this pattern when Salesforce, Workday, an employee portal, or another application needs to create incidents or service requests in Freshservice and receive the resulting Ticket identifier and status.
Integration direction
Example Mapping
| Freshservice Field | Canonical Field | Target Field |
|---|---|---|
| case.subject | summary | Ticket.subject |
| case.description | requestDescription | Ticket.description |
| case.customerId | requesterExternalId | Ticket.requester_id |
Martini implementation pattern
Martini exposes a controlled API that validates the incoming request, resolves Requester and Department references, applies routing and priority rules, and calls the Freshservice Ticket API. A source correlation ID is checked before creation so timeouts and retries do not create duplicate Tickets; the workflow returns the Freshservice identifier or a structured error.
Martini capabilities used
- API exposure
- workflows
- API consumption
- data validation
- data mapping
- business rules
- idempotency
- error handling
Pattern 3: Propagate selected ticket events
When to use this pattern
Use this pattern when Freshservice Workflow Automator can send an outbound request for a relevant Ticket event or condition and downstream systems need normalized notifications, enrichment, or routing.
Integration direction
Example Mapping
| Freshservice Field | Canonical Field | Target Field |
|---|---|---|
| ticket.id | sourceTicketId | Jira issue.externalTicketId |
| ticket.status | serviceStatus | Jira issue.status |
| ticket.description | workDescription | Jira issue.description |
Martini implementation pattern
A Martini webhook-triggered workflow receives and validates the Freshservice request, retrieves the current Ticket when the notification lacks required fields, maps status and ownership to the target model, and conditionally creates or updates a downstream item. Correlation IDs, duplicate checks, and bounded retries protect against webhook redelivery and transient API failures.
Martini capabilities used
- webhook consumption
- workflows
- API consumption
- data enrichment
- data mapping
- conditional routing
- retry handling
Pattern 4: Reconcile Freshservice assets
When to use this pattern
Use this pattern when Freshservice Assets must be compared with a procurement, inventory, or configuration-management application and the organization needs controlled reconciliation rather than unrestricted bidirectional updates.
Integration direction
Example Mapping
| Freshservice Field | Canonical Field | Target Field |
|---|---|---|
| asset.display_name | assetName | item.displayName |
| asset.asset_tag | assetIdentifier | item.externalId |
| asset.lifecycle_state | lifecycleStatus | item.status |
Martini implementation pattern
A scheduled Martini workflow retrieves paginated Assets, normalizes identifiers and lifecycle states, compares them with the target system, and applies changes only according to the selected system-of-record policy. It isolates custom-field and asset-type differences, records reconciliation results, and routes unmatched or conflicting Assets for review.
Martini capabilities used
- scheduled triggers
- API consumption
- pagination
- data mapping
- reconciliation
- business rules
- exception handling
Applications commonly integrated with Freshservice
Freshservice can be integrated with adjacent enterprise applications through its REST APIs and configured workflow notifications. The appropriate direction and data model depend on the system of record, permissions, account configuration, and the business process being automated.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Create Freshservice Tickets from customer, account, or case activity and return ticket status to customer-service teams. | Salesforce → Martini → Freshservice | Expose a Martini API for Salesforce events, validate and deduplicate the request, map case or customer fields to a Freshservice Ticket, route it to the appropriate Department or Agent group, and return the Freshservice ticket identifier and status. |
| ServiceNow | Coordinate service-management data during platform coexistence, migration, or cross-domain incident routing. | Freshservice → Martini → ServiceNow | Use scheduled or event-triggered workflows to retrieve Freshservice Tickets, Changes, or Problems, map them to ServiceNow models, apply ownership rules, and maintain correlation identifiers for bidirectional updates and retry-safe processing. |
| Workday | Provision or update Freshservice Requesters and organizational information when employees join, leave, or change Departments. | Workday → Martini → Freshservice | Schedule a Martini workflow to retrieve approved worker and organization changes from Workday, transform them into Freshservice Requester and Department payloads, apply lifecycle rules, and perform idempotent updates. |
| Microsoft Entra ID | Align employee identity and access-lifecycle information with Freshservice Requesters and, where appropriate, Agents. | Microsoft Entra ID → Martini → Freshservice | Receive or retrieve identity changes, map stable employee identifiers and department attributes, distinguish Requester and Agent handling, and update Freshservice through permission-aware REST operations. |
| Jira Software | Route selected Freshservice Tickets or Changes to engineering teams and synchronize status or comments. | Freshservice → Martini → Jira Software | Receive selected Freshservice Workflow Automator notifications or poll incrementally, enrich the event with Freshservice REST data, map the service-management object to a Jira issue, and use correlation IDs to prevent duplicate issues. |
| NetSuite | Associate service requests or asset-related activity with customers, contracts, or billing records. | Freshservice → Martini → NetSuite | Use a scheduled or event-driven workflow to retrieve relevant Tickets and Assets, resolve customer or contract references, map fields to NetSuite, and route validation or matching exceptions for review. |
| Slack | Notify support or operations channels about selected ticket events and support controlled workflow initiation through an intermediary API. | Freshservice → Martini → Slack | Receive configured Freshservice outbound requests, validate and normalize the event, format a Slack notification through its API, and optionally accept controlled Slack requests through a Martini API that creates or updates Freshservice Tickets. |
| Microsoft Teams | Publish ticket notifications, escalation messages, or approval-related information to operational teams. | Freshservice → Martini → Microsoft Teams | Use a webhook-triggered or scheduled workflow to select Freshservice events, enrich and transform the payload, send it to Microsoft Teams through its supported API, and record delivery outcomes for retries. |
How to build a Freshservice integration in Martini
Objective
Establish Freshservice access using the authentication method appropriate to the account and workflow, while keeping credentials outside workflow payloads.
Instructions in Martini
- Configure the Freshservice base URL and endpoint details
- Use API key Basic Authentication or OAuth 2.0 as appropriate
- Store keys, tokens, and secrets in secured Martini environment configuration
- Validate permissions for every Freshservice object and operation required
Objective
Select an event-driven, API-led, or scheduled entry point based on Freshservice event coverage and synchronization volume.
Instructions in Martini
- Use a webhook-triggered workflow for supported Workflow Automator notifications
- Use a Martini API when external applications need to submit service requests
- Use a scheduler for incremental synchronization and reconciliation
- Define the expected event, object, and account-specific coverage
Objective
Receive Freshservice notifications or retrieve current resource data through the REST API, accounting for incomplete notifications and paginated responses.
Instructions in Martini
- Call the relevant Freshservice REST resource
- Retrieve current data when an outbound notification is only a signal
- Process list endpoints page by page
- Track high-water marks and pagination state durably where required
Objective
Coordinate validation, enrichment, routing, target writes, and checkpoint updates as one maintainable Martini workflow.
Instructions in Martini
- Validate the request and required Freshservice fields
- Enrich events with related Tickets, Requesters, Departments, or Assets when needed
- Apply conditional routing and system-of-record rules
- Separate recoverable failures from data-quality exceptions
Objective
Convert Freshservice object structures and account-specific custom fields into canonical or destination-specific models.
Instructions in Martini
- Map Freshservice JSON fields to the target schema
- Handle custom fields through configuration-driven mappings
- Normalize statuses, identifiers, timestamps, and ownership values
- Preserve source IDs and correlation IDs for traceability
Objective
Enforce duplicate prevention, permissions, routing, lifecycle, and attachment policies before committing changes.
Instructions in Martini
- Check stable external identifiers before creating Tickets or users
- Distinguish Requesters from Agents
- Apply Department, priority, and ownership rules
- Validate attachment size, type, and destination handling
Common Freshservice data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Tickets | Represent incidents, service requests, and other support or service-management work items. | Salesforce, ServiceNow, Jira Software, Slack, Microsoft Teams, SQL databases | Martini retrieves or receives Ticket data, validates required fields, maps status, priority, requester, department, and custom fields, and uses stable IDs or correlation keys for idempotent processing. |
| Requesters | Represent employees, customers, or other users who submit Tickets and service requests. | Workday, Microsoft Entra ID, Salesforce, identity directories | Martini synchronizes identity attributes using stable employee or customer identifiers, applies lifecycle rules, and keeps Requester mappings separate from Agent permissions and behavior. |
| Agents | Represent Freshservice users who work on Tickets and administer service-management processes. | Microsoft Entra ID, Workday, identity directories, ServiceNow | Martini processes Agents with permission-aware mappings and distinguishes them from Requesters when synchronizing roles, departments, and lifecycle data. |
| Departments | Represent organizational units used for requester assignment, service ownership, and routing. | Workday, Microsoft Entra ID, Salesforce, ServiceNow | Martini maps department identifiers and names, validates routing references, and uses configuration-driven rules because department structures differ between accounts. |
| Changes | Represent planned changes managed through change-management workflows. | ServiceNow, Jira Software, Slack, Microsoft Teams | Martini can retrieve or route Changes, normalize approval and status information, apply ownership rules, and preserve source identifiers for reconciliation. |
| Problems | Represent root-cause records associated with recurring incidents or known issues. | ServiceNow, Jira Software, SQL databases | Martini can map Problems with related Ticket references, apply enrichment and deduplication logic, and send exceptions to an operational review flow. |
Authentication and security considerations
Authentication options
Freshservice supports API key authentication through HTTP Basic Authentication, with the API key used as the username and an arbitrary password value as documented by Freshservice. OAuth 2.0 is also available for supported delegated application scenarios.
API operations are constrained by the permissions of the Freshservice agent or OAuth-authorized application. Access to Assets, Changes, Problems, Releases, and other modules may require additional permissions.
Secure Martini configuration
- Send API keys and OAuth tokens only over HTTPS.
- Store credentials and tokens in Martini secrets or secured environment configuration.
- Use least-privilege Freshservice accounts and test access to each required object.
- Prevent credentials, authorization headers, and sensitive ticket data from appearing in workflow logs.
Operational considerations for Freshservice integrations
Rate limits and pagination
Freshservice applies rate limits and paginates list responses. Martini workflows should handle HTTP 429 responses, respect Retry-After when supplied, use bounded backoff, avoid unbounded parallelism, and process pages explicitly.
Synchronization and idempotency
Use created_at or updated_at where supported, retain a high-water mark with a safety window, and use stable Ticket, Requester, Asset, or external correlation identifiers. This protects against equal timestamps, delayed updates, webhook redelivery, and timeout recovery.
Configuration and schema change
Custom fields, service catalog fields, asset types, workflow rules, and permissions are account-specific. Keep vendor-specific mappings configuration-driven, validate required fields, and test changes before deployment.
Attachments and failures
Attachment operations may require multipart form-data and may have endpoint or plan restrictions. Validate file type and size, preserve metadata, and classify validation, permission, rate-limit, not-found, and transient failures separately.
Why use Martini instead of scripts or point-to-point integrations?
Centralized orchestration
Martini coordinates Freshservice API calls, webhook intake, enrichment, mapping, target writes, and exception handling in maintainable workflows instead of scattering logic across scripts.
Reusable integration assets
Teams can expose controlled APIs, reuse authentication and transformation logic, and apply consistent routing, validation, retry, and correlation policies across Freshservice integrations.
Operational reliability
Scheduled workflows can manage pagination, checkpoints, throttling, and idempotent synchronization, while event-driven workflows can process selected Freshservice notifications without requiring every downstream application to understand Freshservice payloads.
Reduced point-to-point coupling
Martini can map Freshservice objects into canonical models and route them to multiple applications, making account-specific fields and downstream changes easier to isolate than in separate point-to-point scripts.
Frequently asked questions
Freshservice can be integrated through its REST APIs for Tickets, Requesters, Agents, Departments, Changes, Problems, Releases, Assets, Service items, and related resources. Freshservice Workflow Automator can also send outbound webhook-style requests for selected events or conditions, while supported ticket operations can handle attachments. API keys with Basic Authentication and OAuth 2.0 are available authentication options.
Yes. Martini can consume Freshservice REST APIs, receive supported outbound webhook-style requests from Workflow Automator, process attachments where supported, map service-management objects, expose APIs for inbound requests, and orchestrate writes to other applications or databases.
No. A dedicated Freshservice connector is not required. Martini can integrate using Freshservice REST APIs, configured outbound webhook-style requests, supported attachment endpoints, and Freshservice API key or OAuth 2.0 authentication.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Freshservice. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Freshservice, cloud infrastructure, or other third-party systems based on subscriptions, usage, and deployment model.
Use the Freshservice REST APIs as the primary mechanism for resource management and synchronization. Use Workflow Automator outbound webhook-style requests for selected event-driven flows when the required event and fields are available. Use scheduled, paginated synchronization for reconciliation or for objects and events without suitable webhook coverage.
Freshservice can send outbound webhook-style requests through configured Workflow Automator actions for selected events and conditions. This coverage is not a universal event stream across every Freshservice object, so the specific event, fields, and account configuration should be verified before design approval.
Martini can run scheduled workflows that retrieve paginated Freshservice resources, use supported timestamps or filters for incremental synchronization, maintain high-water marks with a safety window, and perform idempotent upserts. Webhook-triggered workflows can complement scheduled synchronization for selected Ticket events.
Martini can classify validation, authentication, permission, rate-limit, not-found, and transient server errors separately, use bounded retries with backoff for recoverable failures, and log correlation information without exposing secrets. Stable Freshservice IDs or external correlation IDs support idempotent updates and duplicate prevention.
Related Martini documentation
Freshservice APIs
Events & Workflows
Mapping & Validation
Integrate Freshservice with Martini
Use Martini to connect Freshservice REST APIs and selected workflow notifications with enterprise applications, databases, files, and messaging systems through secure, maintainable workflows.