Get full job history for specific technician via API

Question

I need to retrieve the complete work order history for a specific technician via the FieldPulse API. Specifically, I am interested in understanding the following:

What is the recommended endpoint and query pattern for filtering work orders by assignee (i.e., assignee_id )? The documentation suggests GET /v1/work_orders?assignee_id={id} , but I am uncertain whether this returns all historical records or only those in non-terminal states. 
 How does pagination behave when filtering by assignee? I have observed cursor-based pagination in other list endpoints, but I need confirmation on whether the cursor parameter is stable across filter combinations, particularly when the underlying dataset may be receiving concurrent updates. 
 Is there a mechanism to retrieve associated metadata—e.g., customer details, location coordinates, completion timestamps—without issuing N+1 requests? The documentation mentions an expand parameter, but its supported values are not exhaustively enumerated. 
 What are the failure modes and edge cases I should account for? Specifically:
 
 How does the API handle requests for a technician ID that has been deactivated or reassigned? 
 Is there a maximum lookback period for historical data, and if so, is this configurable per tenant? 
 Are there rate-limiting considerations specific to filtered queries versus unfiltered list requests?

For context, my use case involves generating quarterly performance reports that aggregate job completion metrics per technician. I am less concerned with real-time consistency than with completeness and accuracy of the historical record. I have confirmed that my API key has work_orders:read and technicians:read scopes.

Any clarification on the query parameters, expansion capabilities, and documented constraints would be appreciated. If there are relevant RFCs or specification documents I should consult, please reference them directly.

Eli Torres (Staff) · Accepted Answer

Hey Omar — good questions, let me work through these. The filtering behavior here is... let's call it "documented optimistically," so I get why the uncertainty.

1. Endpoint and filter behavior 
 GET /v1/work_orders?assignee_id={technician_id} does return all work orders where that technician is the assignee, regardless of status. That includes completed, cancelled, archived — everything. The "non-terminal states only" thing is a rumor I think started because the mobile app defaults to filtering for open jobs. The API doesn't.

2. Pagination stability 
 Yeah, cursor-based with cursor and limit . The cursor is stable for the duration of your paginated fetch unless you're sorting by a mutable field like updated_at . Sort by created_at:asc or id:asc and you're fine. Concurrent updates won't shift your window.

3. Expansions 
 Supported expansions for work orders: 
 GET /v1/work_orders?assignee_id=usr_abc123&expand=customer,location,checklist_responses 
 That gets you the full customer object, location with coordinates, and checklist data in one shot. technician is redundant here since you're filtering by assignee, but it works.

4. Edge cases 
 
 Deactivated technicians: API returns their historical work orders normally. The technician object in the response will have status: "inactive" . 
 No lookback limit that I'm aware of, though very old records (pre-2022) may have incomplete completed_at timestamps due to a migration quirk. 
 Rate limits: Filtered queries count the same against your bucket. The 429 backoff applies per-token, not per query type.

Pro tip: If you're doing quarterly aggregations, consider the API rate limits and batch your requests. For large date ranges, I've seen people hit limits by being too granular.

Let me know if you want a sample script — I have a Python pattern for this exact report use case.

Eli Torres (Staff) · Answer

Ah, yeah — you hit the actual limitation. assignee_id filters on current assignee only. There's no queryable assignee history, which is a gap I'm pushing to get on the roadmap. If you need "who touched this job ever," you'd have to pull the full set (or time-bounded) and filter client-side, or use the audit log API ( /v1/work_orders/{id}/history ) per record, which is obviously not great for bulk reporting.

For sort, the suffix is required — sort=created_at:asc or sort=created_at:desc . The docs are vague here; I'll flag that.

Here's a minimal Python pattern:

def get_all_technician_work_orders(technician_id, session, base_url):
 orders = []
 cursor = None
 while True:
 params = {
 "assignee_id": technician_id,
 "limit": 100,
 "expand": "customer,location",
 "sort": "created_at:asc"
 }
 if cursor:
 params["cursor"] = cursor
 
 resp = session.get(f"{base_url}/v1/work_orders", params=params)
 resp.raise_for_status()
 data = resp.json()
 
 orders.extend(data["data"])
 cursor = data.get("pagination", {}).get("next_cursor")
 if not cursor:
 break
 return orders

For backoff, I'm using urllib3.util.retry with Retry(total=5, backoff_factor=1, status_forcelist=[429, 502, 503, 504]) . The API returns a Retry-After header on 429s but the exponential approach works fine.

Re: assignee history — honestly, if that's a hard requirement, email me. There's an internal endpoint that might become public, and I can get you on the beta list for when we stabilize it.