Usage Issue: JazzHR to GHL

Questions
1

:bullseye: What is your goal?

The goal is to create contact in GHL every time that a new candidate kicks in from JazzHR.

:thinking: What is the problem & what have you tried?

The issue is every time it runs every 5 minutes, it pulls up all the data and use a lot of credits. What we want is just to load the new applicant that is not yet in GHL. So it should suppose to just use 4 to 6 credits in every run.

:clipboard: Error messages or input/output bundles

No error. Just a credit usage issue

:camera_with_flash: Screenshots (scenario flow, module settings, errors)

Screenshot 2026-09-01 231802.png
Screenshot 2026-09-01 231802.png1535×730 153 KB

4

Hey Robert,

You need to setup a webhook

I believe you can find the documentation here: https://share.google/H3MSHF27rRLr7MIVb

5

Yeah this is a classic credit trap. that filter after the data store check only stops duplicate contacts from being added, it doesn’t actually save credits —every applicant still runs through the iterator and the data store lookup, and those count as operations either way.

real fix is further upstream, at your first module where you’re pulling from JazzHR. right now it’s grabbing the full applicant list every single run. if you can filter that pull to only return candidates that changed since the last run (JazzHR’s endpoint should support some kind of “updated since” param), you’d only be processing new stuff instead of the whole list every 5 min.

quick way to set that up:

  1. keep a “last run time” stored somewhere (data store works fine)
  2. use that as a filter on your JazzHR pull
  3. update it at the end of each run

that alone should get you way closer to that 4-6 credits/run you’re expecting. and if JazzHR has any kind of instant notification option for new applicants instead of you polling every 5 min, that’d cut it down even more.

6

Hi Robert, I see what’s causing the high credit usage. The JazzHR step is fetching the full applicant dataset on every 5-minute execution, so Make processes records that have already been handled.

I’d change this to an incremental setup: use JazzHR’s created/updated timestamp (or candidate ID) to track the last processed applicant, then filter out anything already sent to GHL. If JazzHR doesn’t support a reliable “created since” filter, I’d use a Make Data Store to maintain the last processed timestamp/ID.

That way, each run only processes the new applicants and should bring the operation usage much closer to the 4–6 credits you’re targeting.