I’m creating an integration for WorkflowMax, and would like to create a “job updated” trigger.

The WorkflowMax API does not provide webhooks, so a poll-based trigger is needed. The API also does not provide timestamps for when jobs were created or updated, which makes things pretty interesting.

In this situation, what would be the best way to create a trigger that fires whenever jobs are updated? 

Options I can think of:

• Use middleware to store polled data
• Create a more limited trigger that checks a single field for updates - for eg “job status updated” trigger
• Anything else you can think of???

Use middleware to store polled data

Here’s a possible recipe for Zapier CLI that I haven’t tried yet.

1. At each polling interval, send a get request to the API endpoint that we’re looking for updates on
2. Send the API response data to some other service to store it. Pipedream might be a good option to store data (thanks @ForYourIT for the inspiration!)
3. When the next polling interval comes around, retrieve the data from step 2 and compare both datasets. Return any items that have been edited 

No idea if this would work or not - has anyone tried anything similar before?

Trigger from changes to a single field

There’s a handy hack from Zapier legacy builder docs where we send a timestamp to the zapier deduper via the id field.
 

Unfortunately WorkflowMax doesn’t provide an updatedAt field or anything similar, nor does it provide any information about when a job was created. 

We can make some progress by replacing updatedAt with a different field, for example job.State:

//Polling the https://api.xero.com/workflowmax/3.0/job.api/current endpoint for updates to jobs

return z.request(options).then((response) => {
    response.throwForStatus();

    //....

    results = results.map((job) => {
      //create an "id" field for the zapier deduper
      job.id = job.UUID + " state: " + job.State; 
      return job;
    });

    //....

});

There’s one problem. According to my testing, this works but it also triggers on conditions that we don’t want. We don’t just get updated jobs - this trigger runs whenever a new job is created too.

As a workaround for this problem, front end users could add storage steps and filters to their zap (kind of like this idea from @BlakeBailey, but in reverse). That’s a pretty annoying workaround for users though. Is there a more graceful way this could be taken care of behind the scenes?