Each case below was reproduced on more than one job.
- Individual job edit - If-Modified-Since catches it, the job log records it, the webhook fires.
- Bulk add tag - If-Modified-Since misses it. The job log records it and the webhook fires.
- Bulk change due date - If-Modified-Since catches it and the job log records it, but the webhook does not fire.
- Bulk change stage - If-Modified-Since catches it and the job log records it, but the webhook does not fire.
Bulk due-date and stage changes do not fire job.updated. Both update DateModified correctly, but no delivery ever arrived, while a bulk tag change on the same build reached the same endpoint almost immediately.
So the two mechanisms fail in opposite directions and neither is a superset of the other. The only thing that caught all of them was polling /logs/jobs/ and pattern-matching the free-text Message field, which means inferring "the due date changed" from English prose. The range of message wordings on a live build is wide, so any change on your side would silently break a customer's sync.
What would help, in order of preference:
- Update DateModified on every write path, including the bulk actions, so If-Modified-Since is a reliable change feed. This is the one that matters most to us.
- Time granularity on DateLogged filters (currently date-only, a value with a time component is rejected) plus a documented set of log message types.
- Change feed endpoint, e.g. GET /jobs/changes?since=<cursor> returning job IDs and changed fields.
Is there a supported approach we have missed?
DEVELOPER CENTER