Slow fields
Some fields in upstream APIs are expensive to fetch because they require extra API calls per record. We call these slow fields.
Slow fields let you choose between faster responses and more complete data. You control the default behavior at the workspace level, and you can always override it per request with the fields query parameter.
What are slow fields?
Slow fields are resource fields that require additional API calls to fetch from the upstream provider.
Examples:
- A job application’s
offersin Greenhouse requires a separate API call per application. - Nested raw objects may expose additional slow fields like
raw.offers.
Because these fields can be expensive to retrieve, we treat them specially:
- They can be excluded by default to keep responses fast.
- They can be included when explicitly requested using the
fieldsparameter. - Or they can be included by default if you prefer completeness over latency.
Workspace setting: Slow fields opt-in
You can control how slow fields behave by default from your workspace settings in the Unified app under Settings → Workspace → Slow fields opt-in (workspace settings).
false(Opt-out / recommended default)- Slow fields are excluded by default.
- Fewer upstream calls and lower latency.
- Slow fields are only fetched when explicitly requested via
fields.
true(Opt-in)- Slow fields are included by default.
- Responses are more complete.
- Responses can be slower due to additional API calls.
You can still override this default on any request using the fields parameter. For a general overview of how fields works (including raw fields), see Working with Custom & Original Fields.
How slow fields interact with fields=…
You can control which fields are returned using the fields query parameter. The behavior depends on how you’ve configured Slow fields opt-in for your workspace.
When Slow fields opt-in is set to Opt-out (default)
Slow fields are excluded unless you request them:
GET /ats/{connection_id}/application
Returns standard (fast) fields only.
GET /ats/{connection_id}/application?fields=offers
Returns only the offers field (a slow field; this may trigger extra upstream API calls).
GET /ats/{connection_id}/application?fields=job_id,candidate_id
Returns only the requested fast fields (no slow fields).
When Slow fields opt-in is set to Opt-in
Slow fields are included unless you filter them out:
GET /ats/{connection_id}/application
Returns all fields, including slow fields (slower, more complete).
GET /ats/{connection_id}/application?fields=job_id,candidate_id
Returns only the requested fields (fast, excludes other slow fields).
GET /ats/{connection_id}/application?fields=job_id,offers
Returns job_id plus the offers slow field (may trigger extra upstream API calls).
Raw objects and slow fields
The same logic applies to nested raw objects:
fields=raw.offers
Requests the slowoffersfield inside the raw payload.fields=raw.last_activity_at
Requests only a non-slow raw field (no extra API calls).
Slow fields are always explicit: if you do not request them (and your workspace is not opted in by default), they will not be fetched.
When to opt in vs opt out
Recommended patterns:
- High‑volume or latency‑sensitive traffic
- Set Slow fields opt-in to Opt-out.
- Only request slow fields when you actually need them, via
fields=….
- Comprehensive data syncs or backfills
- Set Slow fields opt-in to Opt-in, or
- Leave it as Opt-out and explicitly request all needed slow fields with
fields.
- Webhooks and push-based flows
- Configure the
fieldsparameter to include only the fields your consumer needs. - Avoid including slow fields unless your webhook handler can tolerate the extra latency.
- Configure the
Identifying which fields are slow
Slow fields are integration- and object-specific. For example:
- Greenhouse Applications:
offers,raw.offers
Other integrations and object types may expose different slow fields. To see which fields are slow for a given object, check the integration-specific documentation or contact support.