1. Data Controller
WebhookKit is operated by:
Dariusz Zbyrad
Email: [email protected]
For personal data processed by WebhookKit for its own purposes, Dariusz Zbyrad is the data controller.
When a WebhookKit user sends or causes data to be sent to a webhook endpoint, that user may be the controller of the personal data contained in the webhook payload, while WebhookKit processes such data on the user's behalf.
2. Data We Process
When you use WebhookKit, we may process:
- technical information about webhook requests, including HTTP method, path, query parameters, headers, request body, source IP address, timestamps, request size and response status;
- endpoint identifiers, access tokens, endpoint configuration and, when signed in, the association between your account and its endpoints;
- account information received from Google or GitHub when you choose that provider for sign-in: a provider identifier, verified email address and name, together with profile changes you make in WebhookKit;
- sign-in session identifiers, sign-in and last-activity times, and browser/device labels derived from the User-Agent to display and manage active devices;
- technical and security information, including IP address, browser and operating-system information, language information, security identifiers and anti-abuse events;
- server access logs with the request time, full client IP address, User-Agent, HTTP method, full URL including path and query parameters, response status, timing and request identifiers, to operate, secure and troubleshoot the service;
- information stored in your browser as described in the Cookies and Browser Storage Policy.
Webhook payloads are provided by users or external systems. Their contents are not determined by WebhookKit and may contain personal data, credentials, cookies, API keys or other confidential information. Request bodies, received headers and query parameters are not automatically redacted. Access to captured requests requires the endpoint management credential or a session for the owning account.
For abuse prevention, we derive pseudonymous security identifiers from IP addresses, network prefixes and a combination of browser, operating system and language information. These identifiers are not anonymous data. Automated checks may limit endpoint creation, request a security challenge or temporarily block activity.
Contact form submissions contain the name, email address and message you enter. They are stored separately from accounts and webhook history, without a CAPTCHA token, account/session identifier, IP address or User-Agent in the submission record. Please do not include credentials or webhook payloads. Cloudflare Turnstile verifies the contact security challenge; short-lived in-memory admission limits also help prevent abuse.
3. Why We Process Data
We process personal data:
- to provide WebhookKit and its requested functionality — Article 6(1)(b) GDPR;
- to prevent abuse, fraud and attacks and to maintain the security and reliability of the service — Article 6(1)(f) GDPR, based on our legitimate interest in protecting WebhookKit and its users;
- to comply with applicable legal obligations, where necessary — Article 6(1)(c) GDPR.
Contact information is used to handle your question, feedback or problem report.
Account and session data let you sign in, manage your profile and devices, and access your endpoints across browser sessions. On sign-in, eligible anonymous endpoints from your browser session are linked to your account, subject to the account limit.
Webhook payloads are processed to provide the webhook processing service. Request records remain subject to the retention described below unless deleted earlier through Delete captured requests or Delete endpoint. Previously created backups are separate.
4. Service Providers
We may disclose or make data available only where necessary to providers that support the operation and security of WebhookKit, including hosting and infrastructure providers.
Google and GitHub provide optional sign-in. When you choose one of them, your browser is redirected to that provider, which receives information about your connection and sign-in to WebhookKit and returns identity information to us. We do not receive your provider password. We do not request access to Gmail messages, Google Drive files or GitHub repositories. Google and GitHub handle activity on their services under their own privacy policies.
Cloudflare also delivers and protects traffic to the website, application API and webhook endpoints. It can process connection information and the content passing through its network, including webhook headers and bodies.
WebhookKit uses Cloudflare Turnstile for protection against automated abuse. Turnstile may process technical signals such as your IP address, User-Agent, TLS fingerprint and information about the website on which the challenge is used.
We do not sell personal data or use advertising analytics. When optional product analytics is enabled and you allow it in Data preferences, we measure fixed public page and catalog views, local tool actions, CTA clicks, endpoint creation and debugging, response configuration, filters and exports, replay actions and durable outcomes, help/contact/security actions and sign-in completion (including returning sign-ins). Tool input and output data never enter analytics. Events use a random identifier valid for up to 24 hours in one browser tab, approved campaign/referrer labels, CTA location, guest/signed-in state, endpoint lifetime category, HTTP method, content-type category, time to first receipt boolean guest-transfer results, fixed page/tool/action/error categories, receipt provenance and replay delivery evidence. Local-tool documents permit only the configured API origin for optional metadata and necessary withdrawal; processing workers remain network-isolated. We do not send webhook bodies, headers, query values other than explicitly approved campaign labels, tokens, full URLs, source IPs, emails or account identifiers to analytics. No third-party analytics provider or fingerprinting is used. Data stays in our PostgreSQL database. You can reject or withdraw Analytics without losing product functionality.
Withdrawal stops browser collection and requests deletion of this visit's analytics events and endpoint/replay associations. Pending withdrawal retries continue after reload and while collection is disabled; only pending visit identifiers are retained for this purpose. Server-side removal requires connectivity; the visit expires after at most 24 hours even if withdrawal cannot reach the server. Analytics records are eligible for deletion after 30 days, normally by hourly cleanup; service interruptions can delay physical removal. Previously created backups follow the backup retention described below.
4A. Planned Pro payment processing
Pro cannot currently be purchased, and WebhookKit has no Paddle payment integration. When paid Pro subscriptions launch, Paddle is expected to act as Merchant of Record and process purchases, renewals, billing support and refunds. WebhookKit expects to receive or use only information needed to provision and manage access, such as customer email, Paddle customer and subscription identifiers, purchased plan, subscription status, relevant transaction information, and billing and renewal dates. These are anticipated categories, not a claim that we already store them. We do not intend to receive or store payment-card details or send webhook payloads to Paddle.
For that future processing, WebhookKit expects to use subscription information to deliver paid access under Article 6(1)(b) GDPR, maintain accurate records and meet legal obligations under Article 6(1)(c), and address fraud or disputes where justified under Article 6(1)(f). Paddle and WebhookKit may act as independent controllers for relevant shared buyer data under Paddle's Data Sharing Addendum; Paddle's own processing is described in its Privacy Policy. The precise data flows, retention and any international-transfer details must be confirmed before launch. Current webhook capture, account deletion and backup rules above and below remain unchanged.
5. International Transfers
Google, GitHub and Cloudflare may process personal data outside the European Economic Area.
Where required by the GDPR, international transfers are protected using applicable safeguards, including the EU-U.S. Data Privacy Framework or the European Commission's Standard Contractual Clauses.
6. Data Retention
Contact submissions expire 180 days after receipt. An automatic cleanup normally runs hourly in bounded batches; downtime or backlog can delay physical removal. Administrative reads exclude expired messages. Backups follow the separate lifetimes below and do not reset the expiry: expired contact messages must be removed after restore before administrative access.
Guest webhook endpoints expire after 24 hours by default. After plan-policy activation, newly created account-owned endpoints start with 7 days; older account endpoints keep their existing expiry. Signing in or linking an endpoint to an account does not extend its lifetime or the retention of captured requests. A signed-in owner can extend an active, unexpired endpoint to 7 days from the time of extension, without shortening a longer existing deadline. Extensions do not accumulate days or change captured-request retention. Current configured limits and lifetime are shown in the product.
Expiry prevents further normal use of the endpoint, but does not by itself immediately delete the stored endpoint or captured webhook requests.
Delete captured requests permanently deletes the endpoint’s captured request records from the active database, including body, headers, URL path, query parameters, technical request metadata and any previously hidden requests. The endpoint remains active and can receive new requests. No captured payload is retained as a diagnostic copy by this operation. A minimal endpoint lifecycle record (first receipt time, HTTP method category, content-type category and guest/signed-in state at receipt) remains until the endpoint itself is physically removed; it contains no payload, headers, query, source IP or credentials. Optional analytics events follow their separate retention and withdrawal rules. Previously created backups are separate, as described below.
Delete endpoint stops new webhook ingestion, removes the endpoint from your workspace and deletes all of its captured request records from the active database. The deactivated endpoint identity and response configuration may remain until periodic endpoint cleanup, allowing safe retries. Operational creation counters and security events follow their own retention periods. Previously created backups are separate.
Your account profile and Google or GitHub identity associations are retained while your account exists. In Account → Security, you can delete your account by confirming your email address. This deletes the profile and provider associations from the active application database, signs out all devices, disables owned endpoints and removes their account association. Captured requests remain without an account association for audit and security purposes until their originally assigned capture deadline (24 hours or 7 days under the corrected policy; 30 days for earlier admissions). Their contents are not anonymized; personal data within webhook bodies, headers or query parameters may still be present. Signing in again creates a new account and does not restore these endpoints or requests. Deleting your WebhookKit account does not delete your Google or GitHub account or remove permissions in the provider's account settings.
Account sessions expire after 7 days of inactivity and can end earlier when you sign out, revoke a device session or delete your account.
After plan-policy activation, newly created endpoints keep only the newest 50 guest / 500 account captured requests; older records are deleted on a new capture. Endpoints created before activation remain uncapped by count, including after claim by an account. Claim raises a capped guest endpoint to 500. Count eviction can end access before the age cutoff and also invalidates retained replay source payloads.
When the corrected plan policy is activated, new admissions receive a deadline of 24 hours for Anonymous / 7 days for Developer, measured from receipt, including arrivals on existing endpoints. Earlier admissions keep their original 30-day deadline. Claim, renewal and account deletion never reset an assigned deadline. Captures become inaccessible and eligible for permanent database deletion at that deadline. A background cleanup task normally runs hourly; actual deletion can occur later during downtime or backlog. The transition effective time is communicated before activation.
Guest session identifiers are normally valid for up to 30 days. Expired guest-session records are removed by periodic cleanup once no endpoint refers to them. Inactive or expired endpoints and their response configurations are deleted by a separate cleanup task, normally hourly, once no captured requests remain. Empty inactive or expired endpoints are eligible at the next run. Cleanup delays may extend physical retention; active, unexpired endpoints are preserved.
Daily incoming admission uses an opaque hash of the guest endpoint creator’s trusted IP, shared across guest sessions, or an account identifier. Shared networks share the guest quota. Legacy guest endpoints temporarily use session or endpoint attribution. Admission counters are separate from captured history and are not reset by clear or endpoint deletion. Cleanup retains at least the current and previous UTC day; older counters are removed in bounded periodic batches, subject to service delays. The creator-IP hash remains on the endpoint until its physical cleanup.
Security events are scheduled for deletion after 30 days. Short-term anti-abuse counters are removed after their applicable retention window. Periodic cleanup or service interruptions may delay physical deletion.
Nginx access logs are rotated daily and normally kept for about 14 days (the current file and 13 daily archives). Rotation or host outages can delay physical deletion. Full URLs can include webhook public tokens and other information placed in paths or query parameters. File access to these logs is restricted to server administrators. Other technical logs are retained only for as long as reasonably necessary for security, troubleshooting and operation of the service.
Database backups are separate from the active database. Previously created backups may still contain deleted profiles, account associations, contact submissions and captured requests after their removal from the active database. They are not subject to the captured-request cleanup task or its capture deadlines. Pre-deployment copies are scheduled for deletion after 7 days, and regular encrypted copies after 56 days, measured from the copy’s creation or, for pre-deployment files, last write. Separate cleanup tasks normally run hourly, even if no new backup succeeds. Downtime, an operation holding a backup lock or cleanup failures may delay physical deletion.
Automatic reapplication of request and account deletions after restoring a backup is not implemented yet. A backup may therefore contain records deleted since it was created. Restored data must not be made available to users until the applicable deletions have been reconciled; the supporting restore mechanism is scheduled for a later stage.
Browser-side storage is retained as described in the Cookies and Browser Storage Policy.
7. Your Rights
Where the GDPR applies, you may have the right to:
- access your personal data;
- correct inaccurate data;
- request deletion or restriction of processing;
- object to processing based on legitimate interests;
- receive data in a portable format where applicable.
You can edit your name in Account → Profile, manage signed-in devices and delete your account in Account → Security. Your sign-in email is managed through your selected provider, Google or GitHub. For other requests or to exercise your rights, contact [email protected].
If personal data about you were included in a webhook payload by a WebhookKit user, that user may be the relevant data controller. In such cases, we may refer your request to that user or assist them in responding to it.
You also have the right to lodge a complaint with a competent data protection authority. In Poland, this is the President of the Personal Data Protection Office (UODO).
8. Contact
For questions concerning privacy or personal data:
Dariusz Zbyrad
[email protected]