-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new endpoint to ingest events based on the URL #1113
Labels
feature
New feature or request
Comments
lauri865
changed the title
Add new endpoint to ingest events based on URL
Add new endpoint to ingest events based on the URL
Feb 7, 2024
This is a really solid idea, and definitely eases the path when pushing events into inngest via our event format. We're planning an improvement to webhooks now, and we'll definitely take this into consideration. Thanks for the feedback and such a clear, well thought out comment pushing it forward! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
3rd party webhooks have a suboptimal DX today, with no support for local dev server, as well as some observability features lacking that are on the roadmap (e.g. https://roadmap.inngest.com/roadmap?id=3955d73d-a173-4c75-b05a-c89049f7de14).
Describe the solution you'd like
Instead, this could be tackled with a new ingestion endpoint that keeps the webhook workflow close to the core functionality of Inngest.
On top of the current event ingestion endpoint of
/e/{key}
which gets the event name from the body, it would be great to have an end point to trigger events based on URL path or searchparams:E.g.
/e/{key}/{event_name}
or
/e/{key}?name={event_name}
These endpoints should expose the POST body (if any) as event
data
, meaning:could be equivalent to:
As a result 3rd party webhooks could push to this endpoint. Transform function would be an event that invokes other events instead of something configured in the dashboard of the cloud offering. We get the full observability into the flow, a nice local dev experience, and the same ability to push new webhook handlers into production via CI/CD as normal events.
Additional feature request could be to expose request headers and query params into the event context. But not a necessary condition for this to be useful.
I feel like this could open up many new workflows with minimal amount of code to manage for Inngest, compared to the current webhooks implementation.
Link to a message I posted on Discord related to this: https://discord.com/channels/842170679536517141/1159637389501808681/1204756464837591081
The text was updated successfully, but these errors were encountered: