Zapier Trigger Webhook
Push app events to a Zapier catch hook so users can continue the work elsewhere.
What it adds
An outbound event delivery to a user-supplied Zapier hook URL, with event selection, signing, retries, and a delivery log.
What your agent is told to do
5
What your agent is told to do
5-
1
Find the events the app already records internally — record created, status changed, payment received — and expose that existing list as the set a user can subscribe to. Do not invent a parallel event stream just for this integration.
-
2
Deliver every event through the app's existing background-job system, never inline in the request that caused it. A slow or unreachable hook must not delay the user's save.
-
3
Give each delivery a stable identifier that stays the same across every retry of that event, and put it in the payload so the receiving side can discard duplicates.
-
4
Store the destination URL encrypted at rest, show it only to workspace members who may edit the integration, and never render it or the signing secret into client-side code.
-
5
This brief owns the Zapier-facing configuration only. The delivery pipeline — queueing, signing, retry schedule, log, and auto-disable — is shared with the Make Scenario Trigger and n8n Workflow Trigger briefs; build it once and let all three destinations register against it.
Edge cases it handles
8
Edge cases it handles
8- A user can paste any URL, including one that resolves to a private address, a loopback interface, or a cloud metadata endpoint. Require HTTPS, resolve the host before connecting, and refuse targets inside internal network ranges so the integration cannot be used to reach services behind the app.
- A receiver has no way to know a payload genuinely came from the app unless it is signed. Sign every outgoing body with a per-integration secret, include a timestamp in the signed material so an old capture cannot be replayed, and document the scheme in the integration's settings screen.
- Retries and at-least-once delivery mean the same event will arrive more than once. Carry a stable event identifier so the receiving workflow can deduplicate rather than creating the same downstream record twice.
- Users need to confirm a hook works before trusting it with real activity. Provide a test delivery that is clearly flagged as a test in the payload and excluded from the production event history, so nobody wires a live workflow to sample data.
- An endpoint that has been deleted or has returned permanent failures for a long stretch will never succeed. Stop delivering after a defined run of permanent errors, mark the integration disabled, and tell the owner what happened and how to re-enable it.
- The receiving service will rate limit or time out under load. Back off with increasing delays plus jitter, cap the total retry window, and treat a timeout as retryable while treating an authorization rejection as permanent.
- Events fired in bulk — a large import, a batch status change — can produce thousands of deliveries at once. Bound how many are in flight per integration so one workspace cannot starve the queue for everyone else.
- A payload built from an internal record will leak whatever the record holds. Send a deliberately chosen field set, exclude secrets, internal notes, and other users' personal data, and version the payload shape so it can change without silently breaking live workflows.
Definition of done
9
Definition of done
9- Users select which event types are delivered, and nothing is delivered by default.
- Every delivery is queued and never blocks the user action that produced it.
- Outgoing payloads are signed, and each carries a stable identifier that survives retries.
- Destination URLs are validated as external HTTPS targets, and internal-network addresses are rejected.
- Test deliveries are distinguishable from production events and kept out of the production history.
- Repeated permanent failures disable the integration and notify its owner.
- A delivery log shows attempts, response status, and outcome for each event.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Contentful Entry Sync
Contentful Entry Sync
Create and update Contentful entries against the connected space, environment, and locale.
What it does
A sync that writes app records into Contentful entries using the connected space's content model and locale configuration.
How it works
- 1 Have the operator select the space, the environment, and the default locale during connection, and store all three, because writing production content into a sandbox environment is an easy and expensive mistake.
- 2 Fetch the content model at connection time and again before each sync run, map app fields to entry fields by their stable identifiers, and validate the value type against the model before attempting the write.
- 3 Write every localized field under an explicit locale rather than relying on whatever the space treats as default, and state clearly which locales the app owns and which it leaves to editors.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/contentful-entry-sync
Typesense Index Sync
Typesense Index Sync
Keep a search index in step with your records so results stay current and correctly scoped.
What it does
A one-way sync from the app's records into a Typesense collection, with server-enforced tenant filtering and a rebuild path.
How it works
- 1 Identify every model users search today and declare the indexed shape explicitly: the fields people type into, the fields they filter and sort on, and nothing more. Treat a missing or newly added field as absent rather than letting the document fail validation.
- 2 Reuse the app's existing background-job system to push creates, updates, and deletes. Do not index inside the request cycle; a slow or unreachable search service must never make a save fail or hang.
- 3 Build the tenant, workspace, and permission filter on the server at query time and attach it to every search. Do not accept a filter, collection name, or scope value from a client-supplied parameter, because anything the browser can set the browser can change.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/typesense-index-sync
Mapbox Geocoding
Mapbox Geocoding
Convert typed locations into coordinates and structured addresses the app can use.
What it does
Forward and reverse geocoding with confirmed matches, controlled result bias, and coordinate precision rules.
How it works
- 1 Separate the two directions explicitly: text to coordinates for entry and search, coordinates to address for a dropped pin or a device location. They take different inputs, carry different confidence, and fail differently.
- 2 Present ambiguous matches as a list the user confirms. Silently taking the first result is how a record ends up in the wrong country with nobody noticing for months.
- 3 Bias results toward a location only when the app genuinely knows one, such as a workspace address or the map viewport the user is already looking at.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/mapbox-geocoding
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.