Overview
Webhooks allow you to receive real-time notifications when your zip creation jobs complete. Instead of polling the status endpoint, ZipKit will automatically send an HTTP POST request to your specified URL when a zip finishes processing.Why Use Webhooks?
- ✅ Real-time notifications - Get instant updates when zips complete
- ✅ Reduce API calls - No need to poll the status endpoint repeatedly
- ✅ Better user experience - Respond immediately to completed zips
- ✅ Reliable delivery - Webhooks are sent as soon as the job completes
Configuring Webhooks
Webhooks are configured through the ZipKit dashboard for your project.Step-by-Step Setup
1
Navigate to Webhooks
- Log in to your ZipKit dashboard
- Select your project
- Go to the “Webhooks” section
- Click “Create Webhook” or “New Webhook”
2
Configure the webhook
URL (Required)
Enter the full HTTPS URL where you want to receive webhook notifications.
Example:
https://api.myapp.com/webhooks/zipkitDescription (Optional)
Add a description to help identify this webhook’s purpose.
Example: “Production webhook for zip completion events”3
Save and test
- Click “Save” or “Create”
- Your webhook will now receive notifications for all zip jobs in this project
HTTPS Required: For security, webhook URLs must use HTTPS (not HTTP). This ensures webhook payloads are encrypted in transit.
Webhook Payload
When a zip completes (successfully or with failure), ZipKit sends a POST request to your webhook URL with a Stripe-style event payload:Event Structure
Failed Zip
When a zip fails, the payload includes an error object:Event Fields
Unique event identifier with
evt_ prefix.Always
"event".The event type. Currently always
"zip.completed".Unix timestamp when the event was created.
The zip object that triggered the event.
Error details when the zip fails. Only present on failed zips. Contains
type, code, and message fields.Zip Object Fields
Unique zip identifier with
zip_ prefix.Always
"zip".The final status of the zip job.Possible values:
"succeeded"- zip was created and uploaded successfully"failed"- zip creation or upload failed
The storage key (filename/path) of the zip archive in the bucket.
Information about the destination bucket.
The cloud storage service (
"s3" or "r2").The name of the bucket where the zip was stored (or attempted to be stored).
The custom metadata object that was provided when the zip was created. Contains any custom data you attached to track user IDs, order IDs, or other contextual information. Returns an empty object
{} if no metadata was provided.The ETag/checksum of the uploaded zip file. Only present for successful uploads.
The size of the zip file in bytes. Only present for successful uploads.
The MIME type of the zip file. Typically
"application/zip". Only present for successful uploads.Implementing a Webhook Endpoint
Your webhook endpoint should:- Accept POST requests with JSON payloads
- Respond quickly (within 5-10 seconds)
- Return a 2xx status code to acknowledge receipt
- Verify the webhook source (optional but recommended)
Best Practices
Respond quickly
Respond quickly
Your endpoint should respond within 5-10 seconds. If you need to perform long-running tasks, process them asynchronously in a background job.
Verify webhook authenticity
Verify webhook authenticity
Since webhooks don’t currently include authentication headers, verify requests by:
- Restricting webhook endpoint access to ZipKit’s IP addresses
- Using HTTPS to ensure requests aren’t intercepted
- Validating the webhook payload structure and data types
- Implementing request signing (future feature)
Handle retries gracefully
Handle retries gracefully
Make your webhook endpoint idempotent. ZipKit may retry sending webhooks if your endpoint fails to respond. Use the event
id or data.object.id to deduplicate events.Log webhook receipts
Log webhook receipts
Log all webhook receipts for debugging and auditing purposes.
Return proper status codes
Return proper status codes
- Return
200or204for successful receipt - Return
401for authentication failures - Return
500only for actual server errors
Use HTTPS with valid certificates
Use HTTPS with valid certificates
Ensure your webhook endpoint uses HTTPS with a valid SSL certificate. Self-signed certificates may cause delivery failures.
Testing Webhooks
Local Development
For testing webhooks locally, use tools like:- ngrok - Creates a public URL for your local server
- localtunnel - Alternative tunneling service
- Webhook.site - Inspect webhook payloads
Production Testing
Create a test webhook that logs all received payloads to verify everything works correctly before going live.Managing Webhooks
Viewing Webhooks
All configured webhooks are listed in your project’s “Webhooks” section, showing:- Webhook URL
- Description
- Creation date
Editing Webhooks
To update a webhook:- Go to “Webhooks” section
- Click “Edit” next to the webhook
- Update the URL, description, or authorization header
- Save changes
Deleting Webhooks
To remove a webhook:- Go to “Webhooks” section
- Click “Delete” next to the webhook
- Confirm deletion
Once deleted, you’ll stop receiving notifications for zip completions. Any in-flight webhooks may still be delivered.
Troubleshooting
Not receiving webhooks
Possible causes:- Webhook URL is incorrect or unreachable
- Your server is blocking requests from ZipKit
- SSL certificate issues (expired or self-signed)
- Firewall blocking incoming requests
- Verify the webhook URL is correct and accessible
- Check server logs for incoming requests
- Ensure HTTPS is properly configured
- Test with webhook.site first to verify ZipKit is sending requests
Receiving duplicate webhooks
This can happen if:- Your endpoint took too long to respond
- Your endpoint returned an error status code
- Network issues caused ZipKit to retry
id to deduplicate.
Securing webhook endpoints
Best practices:- Use HTTPS with valid SSL certificates
- Restrict access to your webhook endpoint by IP address
- Validate the structure and content of webhook payloads
- Log all webhook receipts for monitoring
Security Considerations
Best practices:- ✅ Use HTTPS to encrypt webhook payloads in transit
- ✅ Restrict access to your webhook endpoint by IP address
- ✅ Validate the webhook payload structure and data types
- ✅ Use unique, hard-to-guess webhook URLs
- ✅ Log all webhook receipts for monitoring
- ✅ Implement idempotency to handle duplicate deliveries
Multiple Webhooks
You can configure multiple webhook URLs in a single project for:- Different endpoints for different environments
- Redundancy (send to multiple systems)
- Different services that need to be notified