Gookit
Use Make’s HTTP modules to connect a record-based workflow to Gookit Label API. Send the template ID and selected records as JSON, preserve the accepted job ID, then download the PDF after the job completes.
This guide describes a generic HTTP integration using the documented APIs, not a native Gookit app. We have tested Gookit’s API separately, but have not run this configuration in a Make workspace. Complete the manual test below before enabling scheduling.
Prepare one small request
Create a developer key and the name/SKU template from the batch tutorial. Prepare two items with quantities two and one. Keep this small fixture until you have verified the output and the scenario’s execution history.
Replace its template ID placeholder with your own saved ID. Store the API key in Make’s supported HTTP authentication/credential configuration, with Authorization: Bearer YOUR_DEVELOPER_API_KEY. Do not put it into a source spreadsheet or sample JSON. See the current Make HTTP module documentation for the module version available in your workspace.
Split submission from status checking
Start with two manually operated scenarios. This avoids building a long loop before the first request works.
Scenario 1: create the batch. Use an HTTP request with method POST, URL https://label-api.gookit.co/api/v1/print, content type application/json and the batch body. Parse the response and record jobId when the status is 202.
Scenario 2: check the saved job. Use GET at https://label-api.gookit.co/api/v1/print/JOB_ID, replacing JOB_ID with the saved value and using the same credential. This scenario must not contain a print-submission module.
| Returned state | Route |
|---|---|
pending or processing | Keep the job ID and check it later |
completed | Download the returned URL |
failed | Stop and inspect the job error |
| HTTP error | Resolve it while preserving the saved job ID |
On the completed route, use an HTTP file-download module with the returned url. Do not attach the API Authorization header to that storage request. Save the downloaded file to the destination you selected, or inspect it in the test run first.
Verify quantities before automation
The sample represents two records and three copies. With the tutorial’s ROLL template it produces three PDF pages. Check the names, encoded SKUs and copies, then print on matching stock at Actual Size if this scenario will feed a physical station.
If the source returns multiple Make bundles, decide whether each bundle should produce its own PDF. For one combined batch, aggregate the selected records into an items array before the POST. Do not confuse Make operations with Gookit label counts; they are different billing units.
Automate checks only after the manual path works
Once the first file is correct, persist unfinished job IDs in a store appropriate to your workflow and have a separate scheduled scenario check them. Mark a completed job as delivered so later runs do not repeatedly deliver it. Make’s own schedule and operation limits affect this design; choose an interval that fits your workspace and response-time needs.
For 429, use the API’s Retry-After value before another request. For a timeout after POST, check execution history and any saved response before deliberately creating another batch. An automatic module retry can repeat an accepted job.
The API returns a temporary download URL. Preserve a downloaded copy where your team expects to find labels; a spreadsheet cell containing that URL is not long-term file storage.