A Penpot team webhook can send design events to another service. An access token can read or modify the same team's data through the API. Both are integration controls, but teams often review the token and forget the webhook. Depending on the team role and feature flags, an administrator may be able to configure an outbound destination that receives file, comment, or project events.
Penpot's team roles are Viewer, Editor, Admin, and Owner. Admins can manage membership and team settings. Owners can change any member's role, including transferring ownership, and can delete the team. The integration guide says webhooks are configured at team level and can post event data to a service the team controls. The configuration guide also makes clear that access tokens and webhooks depend on deployment feature flags.
Model the integration boundary
List every enabled webhook by team, destination, event set, secret handling, and owner. Verify that the destination belongs to an approved service and that its URL does not contain an unmanaged credential. If the payload includes file names, comments, or user identities, classify that data before enabling delivery.
A webhook endpoint should authenticate the sender, reject replayed requests, and validate the payload. Penpot payload format and signature support may vary by version, so test the exact deployment rather than assuming a generic signature header. Store the receiver's secret in a secret manager and rotate it with an overlap window.
Access-token review
Access tokens are an alternative to interactive login for internal API use. Tie each token to a named automation account or an owner with a review date. Check whether the token can be scoped and whether the deployment requires a feature flag that may be turned off after an upgrade. A token that works in staging but not production often indicates a configuration difference rather than a permission bug.
Use the team role model to limit who can create integrations. An Editor may need to edit files but should not automatically be able to change the team's outbound webhook. Review this in the application and at the reverse proxy or identity provider where the role is sourced.
What the ZoomEye observation shows
The search used sub_type=all, page 1, and page size 1. app="Penpot" returned no matches, title="Penpot" returned 3,774, and http.body="Penpot" returned 4,415. A public title match is a lead for an exposed design service, but it does not establish whether webhooks or access tokens are enabled. The body count is broad enough to include documentation and templates.
For owned deployments, correlate the public hostname with certificate inventory, asset tags, and DNS. If the service should be internal, verify that the reverse proxy blocks both the UI and the API, not just the dashboard path.
Validate the failure modes
Test a disabled webhook, a receiver timeout, a rejected payload, and a retry. Confirm that the failure does not leak the secret or send duplicate events in a way the receiver treats as a new action. Test token revocation and disabled feature flags. Review logs for outbound destination changes, team-role changes, and repeated delivery failures.
The design goal is simple: only the intended team can create an integration, only the intended receiver can consume it, and removing either side takes effect quickly.