Overview
You already have a ticket-like objects (Zendesk, Jira, internal back office, etc.)
- Retain control over the ground truth
- Clear 1:1 mapping between Fragment and your existing system
When controlling the full task lifecycle, ensure you:
- Close tasks when they become irrelevant or are completed outside of Fragment
- Update task fields to reflect the current state in your system
- Handle edge cases like duplicate task creation and retries
- Implement proper error handling and retry logic to maintain data consistency
Requirements
- You have read the API overview guide
- You have read the API quickstart guide
- You have read the API pick an integration method guide
Objects
Task
: the task object
Endpoints
POST /tasks
: create a taskPUT /tasks/:id
: create or update a task (idempotent)PATCH /tasks/:id
: update a taskPOST /tasks/batch
: bulk create tasksPUT /tasks/batch
: bulk create or update tasks (idempotent)PATCH /tasks/batch
: bulk update tasks
Steps
The goal is to create a 1:1 mapping between your existing ticket objects and Fragment tasks and maintain that mapping up-to-date. At the minimum, you will need to:- Decide on an ID mapping strategy to reliably link Fragment tasks to your existing tickets
- Create a task in Fragment when a ticket is created in your existing system
- Push relevant changes to Fragment when the ticket is updated in your existing system
Fragment has experimental support for webhooks that enable bi-directional sync, please reach out to us if you need to implement this.
ticket.json
1. Map IDs
There are two main options to manage the ID mapping between your existing ticket objects and Fragment tasks:A. ID Hash (recommended)
This method doesn’t require you to store the task ID in your system.
123
, we can generate a UUID like this:
utils.py
If you need to later retrieve the Fragment task from your existing ticket ID, ensure your hashing method is stable and deterministic. The same input should always generate the same UUID. Avoid using timestamps, random values, or other changing data in your hash generation.
B. Store the task ID in your system
This is a good option if you don’t want to generate a UUID for each task or if you want to explicitly store the task ID in your system. First, create the task on Fragment with a/POST
request to the tasks
endpoint.
2. Create tasks
When you’re creating a task in Fragment that is related to an object in your system, it’s recommended to push information like the object id to Fragment as a custom field. Not only would this enable bi-directional sync, but it can also help troubleshooting issues as well as enable operators to easily search for the object in your existing system. For example,sync.py
To avoid double task creation and guarantee idempotency, we recommend using the
PUT /tasks/{uid}
endpoint instead of POST /tasks
.This requires that you generate a stable task ID that is consistent across retries.3. Update tasks
If your existing object is updated, you need to propagate the changes to the corresponding task in Fragment. We assume that you have some change data capture (CDC) solution that will notify you when the ticket is updated. If you don’t have a CDC solution, an easy way to get started is to poll your existing system for updates at regular intervals (every 5 minutes, etc.). Then, you can use thePATCH /tasks/{uid}
endpoint to update the task in Fragment.
update.py
For better throughput, you can use bulk upserts.