8 | A model for event interoperability between event producers and their consumers
9 | to favor better developer experience, robust integration, and infrastructural
10 | efficiency.
11 |
12 |
13 |
14 |
15 |
What are Event Destinations?
16 |
17 | Event Destinations are endpoints where event producers, such as API Platforms
18 | and SaaS, deliver events. Examples of destination types include AWS SQS, GCP
19 | Pub/Sub, Hookdeck Event Gateway, RabbitMQ, Amazon EventBridge, Kafka,
20 | Webhooks, and more.
21 |
4 | Contribute the the Event Destinations Initiative by providing feedback on the
5 | guidelines within the specification, submitting other examples of
6 | implementations, or sharing your support for the initiative.
7 |
70 |
71 |
76 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Event Destinations Initiative
2 |
3 | An initiative to support a new model for event interoperability between event producers and their consumers to favor better developer experience, robust integration, and infrastructural efficiency.
4 |
5 | 
6 |
7 | ## What are Event Destinations
8 |
9 | Event Destinations expand the capabilities of event producers and benefit event consumers by providing more efficient, reliable, and flexible event delivery options. Event Destinations champion a range of event destinations types beyond just traditional webhooks, allowing developers to use the tools they are most familiar with.
10 |
11 | Event Destinations are endpoints or systems to which event producers can send events and give the developer the choice to use the tools they are familiar with directly. For example:
12 |
13 | - Google Cloud Pub/Sub
14 | - AWS SQS
15 | - Hookdeck Event Gateway
16 | - Amazon EventBridge
17 | - Kafka
18 | - RabbitMQ
19 | - And, of course, traditional HTTP webhooks
20 |
21 | Event Destinations benefit event producers and event consumers.
22 |
23 | For event producers:
24 |
25 | - **Efficiency gains**: Reduced failure rates and retried deliveries compared to public HTTP endpoints. Unlock improved performance for high-throughput scenarios.
26 | - **Protocol flexibility**: Leverage more efficient protocols and encodings.
27 | - **Cost & resource efficient**: Smart retry logic, improved deliverability and scalable infrastructure minimize resource consumption, reducing operational costs while ensuring seamless event delivery at any scale.
28 |
29 | For event consumers:
30 |
31 | - **Streamlined infrastructure and operations**: Eliminate the need for API gateways, load balancers, HTTP consumers, and other infrastructure components, reducing maintenance overhead.
32 | - **Reduced developer burden**: Receive events directly to existing or preferred infrastructure and make use of existing and familiar ecosystem tooling.
33 | - **Predictable behavior**: Standardize event expectations—the message bus handles timeouts, retries, and security.
34 |
35 | ## Event Destinations Specification
36 |
37 | The latest draft version of the specification is in [specification.md](specification.md).
38 |
39 | ## Get Involved
40 |
41 | Read [CONTRIBUTING.md](CONTRIBUTING.md) to learn how to contribute to this repository.
42 |
43 | We use GitHub Discussions for:
44 |
45 | - [General discussions](https://github.com/hookdeck/event-destinations/discussions/new?category=ideas)
46 | - [New ideas](https://github.com/hookdeck/event-destinations/discussions/new?category=ideas)
47 | - [Q&A](https://github.com/hookdeck/event-destinations/discussions/new?category=q-a)
48 |
49 | ## Related Initiatives
50 |
51 | - [Async API](https://www.asyncapi.com)
52 | - [CloudEvents](https://cloudevents.io/)
53 | - [Webhook standardization projects](https://webhooks.fyi/learn-more/standards)
54 |
55 | ## Learn More
56 |
57 | Visit the [Event Destinations Initiative website](https://eventdestinations.org) to learn more.
--------------------------------------------------------------------------------
/website/src/pages/index.astro:
--------------------------------------------------------------------------------
1 | ---
2 | import "../global.scss";
3 | import Title from "../components/Title.astro";
4 | import Nav from "../components/Nav.astro";
5 | import Head from "../components/Head.astro";
6 | import Implementations from "../components/Implementations.astro";
7 | import Manifesto from "../components/Manifesto.astro";
8 | import Supporters from "../components/Supporters.astro";
9 | import Guidelines from "../components/Guidelines.astro";
10 | import Contribute from "../components/Contribute.astro";
11 |
12 | const title = "Event Destinations Initiative";
13 | const description =
14 | "A model for event interoperability between event producers and their consumers to favor better developer experience, robust integration, and infrastructural efficiency";
15 | const tags = [
16 | "event destinations",
17 | "send webhooks",
18 | "event delivery",
19 | "event destinations",
20 | "event platform",
21 | ];
22 | ---
23 |
24 |
25 |
26 |
29 |
30 |
31 |
32 |
33 |
34 |
Manifesto
01
35 |
36 |
37 |
38 |
Guidelines
02
39 |
40 |
41 |
42 |
Implementations
03
43 |
44 |
45 |
46 |
Supporters
04
47 |
48 |
49 |
50 |
Contribute
05
51 |
52 |
53 |
54 |
55 |
56 |
57 |
58 |
104 |
--------------------------------------------------------------------------------
/website/src/components/OnThisPage.astro:
--------------------------------------------------------------------------------
1 |
11 |
12 |
61 |
62 |
106 |
--------------------------------------------------------------------------------
/website/src/components/Supporters.astro:
--------------------------------------------------------------------------------
1 | ---
2 | import Quote from "./Quote.astro";
3 | import Avatar from "./Avatar.astro";
4 |
5 | import PatrickMalatack from "../assets/PatrickMalatack.png";
6 | import AlexBouchard from "../assets/AlexBouchard.png";
7 | import FranMendez from "../assets/FranMendez.png";
8 | import PaulAsjes from "../assets/PaulAsjes.png";
9 | import DavidBoyne from "../assets/DavidBoyne.png";
10 | import SagarBatchu from "../assets/SagarBatchu.png";
11 | import LaurenLong from "../assets/LaurenLong.png";
12 | import VladPick from "../assets/VladPick.png";
13 | import AlexPlugaru from "../assets/AlexPlugaru.png";
14 | // import PhilLeggetter from "../assets/PhilLeggetter.png";
15 | import MauriceKherlakian from "../assets/MauriceKherlakian.png";
16 |
17 | const fullQuoteSupporters = [
18 | {
19 | name: "Fran Méndez",
20 | description: "Founder @ AsyncAPI Initiative",
21 | quote: `In his book Flow Architectures, James Urquhart envisions a future where APIs are inherently asynchronous, with synchronous APIs being reserved only for scenarios where they are truly necessary.
The Event Destinations Initiative represents a significant step toward realizing that vision. Enabling API producers to adopt the most efficient and performant methods for sending and receiving asynchronous, non-blocking data is a development I wholeheartedly support—particularly when it is driven by a collaborative and open effort.
22 |
This direction strongly aligns with the vision we champion at AsyncAPI, and the synergy between these efforts is both promising and exciting. I am eager to see the Event Destinations Initiative succeed and contribute to the evolution and blending of API and EDA ecosystems.`,
23 | image: FranMendez,
24 | },
25 | {
26 | name: "Paul Asjes",
27 | description: "Developer Experience Engineer @ ElevenLabs",
28 | quote:
29 | "I've been working with (and often against) webhooks for years, both as a consumer and an implementer, always wishing that we as an industry could come up with something better. In my opinion, Event Destinations are exactly that.",
30 | image: PaulAsjes,
31 | },
32 | {
33 | name: "Lauren Long",
34 | description: "Co-Founder & CTO @ Ampersand",
35 | quote:
36 | "While webhooks solve the problem that the internet wasn't created to be real-time, producing and consuming them at scale is hard. Event Destinations provide a long-awaited set of guidelines that enable seamless connectivity between applications. I'm excited to see the new breed of apps and user experiences that this unleashes.",
37 | image: LaurenLong,
38 | },
39 | {
40 | name: "Sagar Batchu",
41 | description: "Co-Founder and CEO @ Speakeasy",
42 | quote:
43 | "Webhooks are a great idea, suffering from a bad implementation. Event Destinations is an incredible project to move the industry forward with a consumer experience that works for developers, rather than against them.",
44 | image: SagarBatchu,
45 | },
46 | {
47 | name: "David Boyne",
48 | description: "Founder @ EventCatalog",
49 | quote:
50 | "For years, I've been thinking about the evolution of webhooks. Why create them, verify them, manage and scale them? Why can't companies directly send information into brokers? We can simplify the whole thing, and event destinations may be the next step forward. EDA is becoming more accessible for everyone, so why not make handling real-time events easier, too?",
51 | image: DavidBoyne,
52 | },
53 | {
54 | name: "Alex Bouchard",
55 | description: "Co-Founder & CEO @ Hookdeck",
56 | quote:
57 | "Delivering webhooks at scale is hard. Event Destinations represents a required evolution of event delivery, helping event producers scale more efficiently and providing a much improved developer experience for event consumers.",
58 | image: AlexBouchard,
59 | },
60 | // {
61 | // name: "Patrick Malatack",
62 | // description: "Former VP Product @ Twilio",
63 | // quote:
64 | // "At Twilio, we ultimately spent thousands of developer hours building queuing, security, retry logic, and a reverse load balancer to reliably deliver webhooks at scale.",
65 | // image: PatrickMalatack,
66 | // },
67 | ];
68 |
69 | const avatarOnlySupporters = [
70 | {
71 | name: "Vlad Pick",
72 | description: "Engineering Manager @ Attentive",
73 | image: VladPick,
74 | },
75 | {
76 | name: "Alex Plugaru",
77 | description: "Co-founder & CTO @ Gorgias",
78 | image: AlexPlugaru,
79 | },
80 | // {
81 | // name: "Phil Leggetter",
82 | // description: "DX and DevRel @ Hookdeck",
83 | // image: PhilLeggetter,
84 | // },
85 | {
86 | name: "Patrick Malatack",
87 | description: "Former VP Product @ Twilio",
88 | image: PatrickMalatack,
89 | },
90 | {
91 | name: "Maurice Kherlakian",
92 | description: "Co-Founder and CTO @ Hookdeck",
93 | image: MauriceKherlakian,
94 | },
95 | ];
96 | ---
97 |
98 |
10 | Over the last 10 years, webhooks have become the go-to mechanism for
11 | delivering events from developer platforms to support other platform
12 | integrations, custom integrations, and workflows. Webhooks have been
13 | transformative and offer wide compatibility but come with well-known issues:
14 |
15 |
16 | {
17 | [
18 | {
19 | title: "Lack of broadly adopted standards",
20 | description:
21 | "No universal approach to retries, timeouts, security, or payload format.",
22 | },
23 | {
24 | title: "Performance bottlenecks",
25 | description:
26 | "Suboptimal for high-throughput scenarios; no batching, efficient encoding (e.g., Protobuf), or persistent HTTP connections without consumer-side Keep Alive dependency.",
27 | },
28 | {
29 | title: "Opt-in security",
30 | description:
31 | "Security through verification is opt-in and often more complex than API authentication, making secure integrations tedious or incorrectly implemented.",
32 | },
33 | {
34 | title: "High operational & infrastructural costs",
35 | description:
36 | "High failure rates and inconsistent event consumer performance make webhooks expensive to operate and maintain.",
37 | },
38 | ].map(({ title, description }) => (
39 |
40 |
{title}
41 |
{description}
42 |
43 | ))
44 | }
45 |
46 |
47 | Webhooks are the least common denominator. They offer amazing reach but lack
48 | capabilities at scale. How can you combine the reach of webhooks with the
49 | capabilities of other event paradigms? With Event Destinations.
50 |
51 |
52 |
57 | "At Twilio, we would often see spikes in usage, which would lead to us
58 | accidentally DoSing our user's webhook endpoints."
59 |
60 |
61 |
Reimagining event delivery
62 |
63 | Best practices today often dictate validating and queuing webhooks via a
64 | message bus upon receipt. This raises a fundamental question: Why depend on
65 | inefficient public HTTP endpoints? Why not send events directly to secure and
66 | efficient event destinations?
67 |
68 |
69 |
70 |
71 |
The emergence of event destinations
72 |
73 | Pioneers in the industry are shifting away from traditional webhooks toward a
74 | more versatile model. For example, Stripe's Event Destinations allow
75 | developers to select the best destination for their needs - webhooks are just
76 | one of the options. This shift brings clear advantages.
77 |
106 | {
107 | [
108 | {
109 | title: "Streamlined infrastructure & operations",
110 | description:
111 | "Eliminate the need for API gateways, load balancers, HTTP consumers, and other infrastructure components, reducing maintenance overhead.",
112 | },
113 | {
114 | title: "Reduced developer burden",
115 | description:
116 | "Receive events directly to existing or preferred infrastructure and make use of existing and familiar ecosystem tooling.",
117 | },
118 | {
119 | title: "Predictable behavior",
120 | description:
121 | "Standardize event expectations—the message bus handles timeouts, retries, and security.",
122 | },
123 | ].map(({ title, description }) => (
124 |
125 |
{title}
126 |
{description}
127 |
128 | ))
129 | }
130 |
131 |
Better developer experience for all
132 |
133 | At the core of this shift is a commitment to enhancing the developer
134 | experience. Platforms can improve the developer experience by expanding event
135 | delivery options and capabilities, moving beyond only offering traditional
136 | webhooks by supporting Event Destinations such as AWS SQS, GCP Pub/Sub,
137 | Hookdeck Event Gateway, RabbitMQ, and Kafka, to name a few.
138 |
139 |
140 | This DX evolution helps everyone; developers gain tools that are more powerful
141 | and simpler to use and maintain. Developers are more successful and faster at
142 | adopting developer platforms.
143 |
144 |
145 | In particular:
146 |
147 |
148 | {
149 | [
150 | {
151 | title: "Ease of integration",
152 | description:
153 | "Developers no longer need to set up and manage HTTP endpoints, debug connection issues, or manually handle retries and timeouts. Instead, they can focus on building value-driven features.",
154 | },
155 | {
156 | title: "Reduced cognitive load",
157 | description:
158 | "Standardization in retries, security, and performance handling allows developers to rely on consistent, predictable event delivery without reinventing the wheel.",
159 | },
160 | {
161 | title: "Built-in scalability",
162 | description:
163 | "As systems scale, efficient protocols, batching, and proven resilient infrastructure ensure event delivery remains reliable, even under high throughput.",
164 | },
165 | ].map(({ title, description }) => (
166 |
167 |
{title}
168 |
{description}
169 |
170 | ))
171 | }
172 |
173 |
174 | This evolution isn't just about solving pain points—it's about unlocking
175 | possibilities new possibilities for developers building event-driven
176 | applications. By prioritizing interoperability, security, and efficiency,
177 | Event Destinations represent the next step in creating a developer experience
178 | that empowers everyone.
179 |
180 |
The vision
181 |
182 | Webhooks have brought us to where we are today and will undoubtedly remain a
183 | cornerstone of event interoperability for the foreseeable future. However, as
184 | the industry evolves, the path forward lies in progressively adopting
185 | interoperable, secure, and efficient Event Destinations.
186 |
187 |
188 | By enhancing existing webhook capabilities while introducing new destination
189 | types, developers can transition at their own pace, maintain backward
190 | compatibility and leverage the best of both worlds.
191 |
192 |
193 | This incremental approach ensures continuity while enabling innovation,
194 | simplifying event-driven architectures, and creating better developer
195 | experiences for everyone.
196 |
85 |
86 |
87 |
166 |
167 |
382 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | Apache License
2 | Version 2.0, January 2004
3 | http://www.apache.org/licenses/
4 |
5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
6 |
7 | 1. Definitions.
8 |
9 | "License" shall mean the terms and conditions for use, reproduction,
10 | and distribution as defined by Sections 1 through 9 of this document.
11 |
12 | "Licensor" shall mean the copyright owner or entity authorized by
13 | the copyright owner that is granting the License.
14 |
15 | "Legal Entity" shall mean the union of the acting entity and all
16 | other entities that control, are controlled by, or are under common
17 | control with that entity. For the purposes of this definition,
18 | "control" means (i) the power, direct or indirect, to cause the
19 | direction or management of such entity, whether by contract or
20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the
21 | outstanding shares, or (iii) beneficial ownership of such entity.
22 |
23 | "You" (or "Your") shall mean an individual or Legal Entity
24 | exercising permissions granted by this License.
25 |
26 | "Source" form shall mean the preferred form for making modifications,
27 | including but not limited to software source code, documentation
28 | source, and configuration files.
29 |
30 | "Object" form shall mean any form resulting from mechanical
31 | transformation or translation of a Source form, including but
32 | not limited to compiled object code, generated documentation,
33 | and conversions to other media types.
34 |
35 | "Work" shall mean the work of authorship, whether in Source or
36 | Object form, made available under the License, as indicated by a
37 | copyright notice that is included in or attached to the work
38 | (an example is provided in the Appendix below).
39 |
40 | "Derivative Works" shall mean any work, whether in Source or Object
41 | form, that is based on (or derived from) the Work and for which the
42 | editorial revisions, annotations, elaborations, or other modifications
43 | represent, as a whole, an original work of authorship. For the purposes
44 | of this License, Derivative Works shall not include works that remain
45 | separable from, or merely link (or bind by name) to the interfaces of,
46 | the Work and Derivative Works thereof.
47 |
48 | "Contribution" shall mean any work of authorship, including
49 | the original version of the Work and any modifications or additions
50 | to that Work or Derivative Works thereof, that is intentionally
51 | submitted to Licensor for inclusion in the Work by the copyright owner
52 | or by an individual or Legal Entity authorized to submit on behalf of
53 | the copyright owner. For the purposes of this definition, "submitted"
54 | means any form of electronic, verbal, or written communication sent
55 | to the Licensor or its representatives, including but not limited to
56 | communication on electronic mailing lists, source code control systems,
57 | and issue tracking systems that are managed by, or on behalf of, the
58 | Licensor for the purpose of discussing and improving the Work, but
59 | excluding communication that is conspicuously marked or otherwise
60 | designated in writing by the copyright owner as "Not a Contribution."
61 |
62 | "Contributor" shall mean Licensor and any individual or Legal Entity
63 | on behalf of whom a Contribution has been received by Licensor and
64 | subsequently incorporated within the Work.
65 |
66 | 2. Grant of Copyright License. Subject to the terms and conditions of
67 | this License, each Contributor hereby grants to You a perpetual,
68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable
69 | copyright license to reproduce, prepare Derivative Works of,
70 | publicly display, publicly perform, sublicense, and distribute the
71 | Work and such Derivative Works in Source or Object form.
72 |
73 | 3. Grant of Patent License. Subject to the terms and conditions of
74 | this License, each Contributor hereby grants to You a perpetual,
75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable
76 | (except as stated in this section) patent license to make, have made,
77 | use, offer to sell, sell, import, and otherwise transfer the Work,
78 | where such license applies only to those patent claims licensable
79 | by such Contributor that are necessarily infringed by their
80 | Contribution(s) alone or by combination of their Contribution(s)
81 | with the Work to which such Contribution(s) was submitted. If You
82 | institute patent litigation against any entity (including a
83 | cross-claim or counterclaim in a lawsuit) alleging that the Work
84 | or a Contribution incorporated within the Work constitutes direct
85 | or contributory patent infringement, then any patent licenses
86 | granted to You under this License for that Work shall terminate
87 | as of the date such litigation is filed.
88 |
89 | 4. Redistribution. You may reproduce and distribute copies of the
90 | Work or Derivative Works thereof in any medium, with or without
91 | modifications, and in Source or Object form, provided that You
92 | meet the following conditions:
93 |
94 | (a) You must give any other recipients of the Work or
95 | Derivative Works a copy of this License; and
96 |
97 | (b) You must cause any modified files to carry prominent notices
98 | stating that You changed the files; and
99 |
100 | (c) You must retain, in the Source form of any Derivative Works
101 | that You distribute, all copyright, patent, trademark, and
102 | attribution notices from the Source form of the Work,
103 | excluding those notices that do not pertain to any part of
104 | the Derivative Works; and
105 |
106 | (d) If the Work includes a "NOTICE" text file as part of its
107 | distribution, then any Derivative Works that You distribute must
108 | include a readable copy of the attribution notices contained
109 | within such NOTICE file, excluding those notices that do not
110 | pertain to any part of the Derivative Works, in at least one
111 | of the following places: within a NOTICE text file distributed
112 | as part of the Derivative Works; within the Source form or
113 | documentation, if provided along with the Derivative Works; or,
114 | within a display generated by the Derivative Works, if and
115 | wherever such third-party notices normally appear. The contents
116 | of the NOTICE file are for informational purposes only and
117 | do not modify the License. You may add Your own attribution
118 | notices within Derivative Works that You distribute, alongside
119 | or as an addendum to the NOTICE text from the Work, provided
120 | that such additional attribution notices cannot be construed
121 | as modifying the License.
122 |
123 | You may add Your own copyright statement to Your modifications and
124 | may provide additional or different license terms and conditions
125 | for use, reproduction, or distribution of Your modifications, or
126 | for any such Derivative Works as a whole, provided Your use,
127 | reproduction, and distribution of the Work otherwise complies with
128 | the conditions stated in this License.
129 |
130 | 5. Submission of Contributions. Unless You explicitly state otherwise,
131 | any Contribution intentionally submitted for inclusion in the Work
132 | by You to the Licensor shall be under the terms and conditions of
133 | this License, without any additional terms or conditions.
134 | Notwithstanding the above, nothing herein shall supersede or modify
135 | the terms of any separate license agreement you may have executed
136 | with Licensor regarding such Contributions.
137 |
138 | 6. Trademarks. This License does not grant permission to use the trade
139 | names, trademarks, service marks, or product names of the Licensor,
140 | except as required for reasonable and customary use in describing the
141 | origin of the Work and reproducing the content of the NOTICE file.
142 |
143 | 7. Disclaimer of Warranty. Unless required by applicable law or
144 | agreed to in writing, Licensor provides the Work (and each
145 | Contributor provides its Contributions) on an "AS IS" BASIS,
146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
147 | implied, including, without limitation, any warranties or conditions
148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
149 | PARTICULAR PURPOSE. You are solely responsible for determining the
150 | appropriateness of using or redistributing the Work and assume any
151 | risks associated with Your exercise of permissions under this License.
152 |
153 | 8. Limitation of Liability. In no event and under no legal theory,
154 | whether in tort (including negligence), contract, or otherwise,
155 | unless required by applicable law (such as deliberate and grossly
156 | negligent acts) or agreed to in writing, shall any Contributor be
157 | liable to You for damages, including any direct, indirect, special,
158 | incidental, or consequential damages of any character arising as a
159 | result of this License or out of the use or inability to use the
160 | Work (including but not limited to damages for loss of goodwill,
161 | work stoppage, computer failure or malfunction, or any and all
162 | other commercial damages or losses), even if such Contributor
163 | has been advised of the possibility of such damages.
164 |
165 | 9. Accepting Warranty or Additional Liability. While redistributing
166 | the Work or Derivative Works thereof, You may choose to offer,
167 | and charge a fee for, acceptance of support, warranty, indemnity,
168 | or other liability obligations and/or rights consistent with this
169 | License. However, in accepting such obligations, You may act only
170 | on Your own behalf and on Your sole responsibility, not on behalf
171 | of any other Contributor, and only if You agree to indemnify,
172 | defend, and hold each Contributor harmless for any liability
173 | incurred by, or claims asserted against, such Contributor by reason
174 | of your accepting any such warranty or additional liability.
175 |
176 | END OF TERMS AND CONDITIONS
177 |
178 | APPENDIX: How to apply the Apache License to your work.
179 |
180 | To apply the Apache License to your work, attach the following
181 | boilerplate notice, with the fields enclosed by brackets "[]"
182 | replaced with your own identifying information. (Don't include
183 | the brackets!) The text should be enclosed in the appropriate
184 | comment syntax for the file format. We also recommend that a
185 | file or class name and description of purpose be included on the
186 | same "printed page" as the copyright notice for easier
187 | identification within third-party archives.
188 |
189 | Copyright [yyyy] [name of copyright owner]
190 |
191 | Licensed under the Apache License, Version 2.0 (the "License");
192 | you may not use this file except in compliance with the License.
193 | You may obtain a copy of the License at
194 |
195 | http://www.apache.org/licenses/LICENSE-2.0
196 |
197 | Unless required by applicable law or agreed to in writing, software
198 | distributed under the License is distributed on an "AS IS" BASIS,
199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
200 | See the License for the specific language governing permissions and
201 | limitations under the License.
--------------------------------------------------------------------------------
/specification.md:
--------------------------------------------------------------------------------
1 | # Event Destinations Specification
2 |
3 | Status: DRAFT
4 |
5 | ## 1. Introduction
6 |
7 | This specification document outlines a set of guidelines for developers implementing event destinations. By following this specification, developers can ensure that their event destinations implementations are robust, flexible, and capable of handling diverse event delivery scenarios.
8 |
9 | ## 2. What are Event Destinations
10 |
11 | Event Destinations expand the capabilities of event producers, such as API platforms, and benefit event consumers by providing more efficient and reliable event delivery options beyond just traditional webhooks.
12 |
13 | Event Destinations are endpoints or systems to which event producers can send events and give the developer the choice to use the tools they are familiar with directly. For example:
14 |
15 | - Google Cloud Pub/Sub
16 | - AWS SQS
17 | - Hookdeck Event Gateway
18 | - Amazon EventBridge
19 | - Kafka
20 | - RabbitMQ
21 | - HTTP webhooks
22 |
23 | ## 3. Goals
24 |
25 | The goals of this specification are:
26 |
27 | 1. Define guidelines for implementing event destinations that ensures reliability, efficiency, and flexibility.
28 | 2. Provide clarity regarding the guidelines that are **required** and **recommended** to support various event delivery scenarios.
29 | 3. Ensure compatibility with popular event destinations and integration patterns.
30 | 4. Promote best practices for event delivery, including retries, failure handling, and delivery guarantees.
31 |
32 | ## 4. Specification
33 |
34 | This section outlines the required and recommended features for implementing event destinations. The goal is to provide a robust and flexible implementation that can handle various event delivery scenarios efficiently and reliably.
35 |
36 | ### 4.1 Required Features
37 |
38 | These features are essential for any event destination implementation to ensure basic functionality and reliability.
39 |
40 | #### 4.1.1 Support least two event destination types, including webhooks
41 |
42 | The implementation must support at least two types of event destinations. One of these must be HTTP webhooks, given their widespread use and simplicity. The second type can be chosen from other popular event destinations such as message queues or event buses. This requirement ensures that the implementation can cater to different use cases, integrations needs, and preferences of developers.
43 |
44 | Examples of supported event destination types include:
45 |
46 | - HTTP webhooks
47 | - Message queues (e.g., AWS SQS, RabbitMQ)
48 | - Event buses (e.g., Amazon EventBridge, Google Cloud Pub/Sub)
49 |
50 | #### 4.1.2 Automatic delivery retries with exponential backoff
51 |
52 | The implementation must include automatic delivery retries with an exponential backoff strategy. This means that if an event delivery attempt fails, the implementation will wait for a progressively longer period before retrying, up to a maximum number of retries or a maximum wait time. This approach helps to prevent overwhelming the destination with repeated requests in a short period and increases the likelihood of successful delivery over time.
53 |
54 | Key aspects of this feature include:
55 |
56 | - **Configurable retry limits**: Allow developers to set the maximum number of retry attempts and the maximum wait time between retries.
57 | - **Exponential backoff algorithm**: Implement an exponential backoff algorithm to calculate the wait time between retries, typically doubling the wait time after each failed attempt.
58 | - **Error handling**: Properly handle different types of errors (e.g., network issues, server errors) and determine whether a retry is appropriate based on the error type.
59 | - **Logging and monitoring**: Provide logging and monitoring capabilities to track retry attempts, successes, and failures, enabling developers to diagnose and address issues effectively.
60 |
61 | By incorporating automatic delivery retries with exponential backoff, the event destination implementation can achieve higher reliability and resilience in the face of transient failures.
62 |
63 | #### 4.1.3 APIs to create, update and delete destinations
64 |
65 | The implementation must provide APIs to manage event destinations, including creating, updating, and deleting destinations.
66 |
67 | Key aspects of this feature include:
68 |
69 | - **Create API**: An endpoint to create a new event destination. The API should accept necessary parameters such as destination type, destinations URI, authentication details, and any other required configuration settings.
70 | - **Update API**: An endpoint to update an existing event destination. The API should allow modifications to the destination's configuration, such as changing the destination URI, updating authentication details, or modifying other settings.
71 | - **Delete API**: An endpoint to delete an existing event destination. The API should ensure that the destination is properly removed and that no further events are sent to it.
72 |
73 | By providing these APIs, the implementation allows developers to manage their event destinations efficiently and integrate the management of these destinations into their existing workflows and automation processes.
74 |
75 | #### 4.1.4 Alerts for destination failures
76 |
77 | The implementation must include alerting mechanisms to notify developers of destination failures. The implementation must support at least one notification channel.
78 |
79 | Considerations for feature include:
80 |
81 | - **Configurable alert thresholds**: Allow developers to set thresholds for triggering alerts, such as a specific number of consecutive failures or a percentage of failed attempts within a given time frame.
82 | - **Notification channels**: Support multiple notification channels, such as email, SMS, Slack, or other messaging platforms, to ensure that alerts reach the appropriate personnel.
83 | - **Detailed alert information**: Provide detailed information in the alerts, including the destination that failed, the error encountered, and any relevant context or logs to help diagnose the issue.
84 | - **Integration with monitoring tools**: Enable integration with popular monitoring and incident management tools, such as Prometheus, Grafana, or PagerDuty, to streamline the alerting and resolution process.
85 |
86 | By incorporating alerts for destination failures, the event destination implementation can help developers maintain high reliability and quickly respond to issues that may affect event delivery.
87 |
88 | #### 4.2 Recommended Features
89 |
90 | These features are not mandatory but are highly recommended to enhance the overall performance, reliability, and developer experience of the event destination implementation.
91 |
92 | #### 4.2.1 At-least-once event delivery guarantee
93 |
94 | The implementation should provide an at-least-once event delivery guarantee to ensure that events are delivered to the destination at least once, even in the face of transient failures. This means that the system will make multiple attempts to deliver an event until it receives an acknowledgment from the destination, ensuring that no events are lost.
95 |
96 | Key aspects of this feature include:
97 |
98 | - **Acknowledgment mechanism**: Implement a mechanism for the destination to acknowledge the receipt of an event. This could be an HTTP status code, a message queue acknowledgment, or another form of confirmation.
99 | - **Idempotency**: Ensure that the event delivery process is idempotent, meaning that multiple deliveries of the same event do not result in duplicate processing. This can be achieved by including unique event identifiers and having the destination handle duplicates appropriately.
100 | - **Persistence**: Store events persistently until they are successfully delivered and acknowledged by the destination. This ensures that events are not lost in case of system crashes or restarts.
101 | - **Monitoring and logging**: Provide monitoring and logging capabilities to track the delivery attempts and acknowledgments, enabling developers to diagnose and address any issues that may arise.
102 |
103 | By implementing an at-least-once event delivery guarantee, the event destination implementation can provide higher reliability and ensure that all events are delivered, even in the presence of temporary failures.
104 |
105 | #### 4.2.2 Event topics and topics-based subscriptions
106 |
107 | The implementation should support event topics and topic-based subscriptions to allow developers to organize and filter events. This feature enables developers to subscribe to specific topics of interest and receive only the events relevant to those topics.
108 |
109 | Functionality includes:
110 |
111 | - **Subscription management**: Provide APIs to create, update, and delete subscriptions to specific topics. Developers should be able to subscribe to multiple topics and manage their subscriptions.
112 | - **Event publishing**: Allow event producers to publish events to specific topics. The implementation should ensure that events are delivered only to the subscribers of the relevant topics.
113 | - **Filtering and routing**: Implement filtering and routing mechanisms to ensure that events are delivered to the appropriate subscribers based on their topic subscriptions.
114 | - **Monitoring and logging**: Provide monitoring and logging capabilities to track topic creation, subscription management, and event delivery, enabling developers to diagnose and address any issues that may arise.
115 |
116 | By supporting event topics and topic-based subscriptions, the event destination implementation can offer greater flexibility and efficiency in event delivery, allowing developers to tailor their event consumption to their specific needs.
117 |
118 | #### 4.2.3 Auto-disabling of failing destinations after too many failures
119 |
120 | The implementation should automatically disable event destinations that experience a high number of consecutive failures. This feature helps to prevent continuous attempts to deliver events to destinations that are consistently failing, which can save resources and reduce the risk of overwhelming the destination.
121 |
122 | Key aspects of this feature include:
123 |
124 | - **Failure threshold**: Allow developers to configure the number of consecutive failures that will trigger the auto-disabling of a destination.
125 | - **Notification**: Notify developers when a destination is auto-disabled due to excessive failures. This notification should include detailed information about the destination and the errors encountered, similar to the alerts described in section 4.1.4.
126 | - **Re-enabling**: Provide mechanisms for developers to manually re-enable a disabled destination once the issue has been resolved. This can be done through an API or a user interface.
127 | - **Logging and monitoring**: Track and log the auto-disabling events, including the reasons for disabling and any subsequent actions taken by developers. This information can help diagnose and address the underlying issues causing the failures.
128 |
129 | By incorporating auto-disabling of failing destinations, the event destination implementation can improve overall system stability and ensure that resources are used efficiently.
130 |
131 | #### 4.2.4 Developer-facing UI to configure destinations & inspect events
132 |
133 | The implementation should provide a user-friendly interface (UX) for developers to configure event destinations and inspect events. This feature enhances the developer experience by making it easier to manage event destinations and troubleshoot issues.
134 |
135 | Key aspects of this feature include:
136 |
137 | - **Configuration UI**: A web-based interface that allows developers to create, update, and delete event destinations. The UI should provide forms and validation to ensure that all necessary information is collected and correctly formatted.
138 | - **Event inspection**: A tool within the UI that allows developers to view and search through events that have been sent to destinations. This tool should display event details, including payload, headers, and delivery status.
139 | - **Filtering and sorting**: Enable developers to filter and sort events based on various criteria, such as destination, status, timestamp, and payload content. This helps developers quickly find relevant events and diagnose issues.
140 | - **Error details**: Provide detailed error information for failed events, including error messages, stack traces, and any relevant logs. This information can help developers understand why an event delivery failed and how to fix the issue.
141 | - **Integration with APIs**: Ensure that all actions available in the UI can also be performed via APIs, allowing developers to automate the management of event destinations and event inspection.
142 |
143 | By offering a developer-facing UX for configuring destinations and inspecting events, the event destination implementation can improve usability and streamline the process of managing and troubleshooting event deliveries.
144 |
145 | #### 4.2.5 Manual retries via UI or API
146 |
147 | The implementation should allow developers to manually retry event deliveries via the user interface (UI) or an API. This feature provides flexibility for developers to address and resolve issues with event delivery on a case-by-case basis.
148 |
149 | Key aspects of this feature include:
150 |
151 | - **Retry via UI**: Provide a user-friendly interface that allows developers to select one or more failed events and trigger a manual retry. The UI should display relevant information about the events, such as payload, headers, and error details, to help developers decide which events to retry.
152 | - **Retry via API**: Offer an API endpoint that enables developers to programmatically trigger retries for specific events. This allows for automation and integration with other systems or workflows.
153 | - **Retry limits**: Implement configurable limits on the number of manual retries to prevent abuse or excessive resource consumption. Developers should be able to set these limits based on their requirements.
154 | - **Logging and monitoring**: Track and log all manual retry attempts, including the user or system that initiated the retry, the events retried, and the outcomes. This information can help diagnose issues and improve the reliability of event delivery.
155 |
156 | By providing manual retries via UI or API, the event destination implementation can offer greater control and flexibility for developers to ensure successful event delivery.
157 |
158 | #### 4.2.6 Filtering based on payload content
159 |
160 | The implementation should support filtering events based on their payload content. This feature allows developers to define rules that determine which events should be delivered to specific destinations based on the content of the event payload.
161 |
162 | Key aspects of this feature include:
163 |
164 | - **Rule definition**: Provide a mechanism for developers to define filtering rules based on payload content. These rules can be based on specific fields, values, or patterns within the payload.
165 | - **Flexible conditions**: Support various conditions for filtering, such as equality, inequality, contains, starts with, ends with, and regular expressions. This flexibility allows developers to create precise and complex filtering criteria.
166 | - **Configuration UI**: Offer a user-friendly interface for creating and managing filtering rules. The UI should allow developers to define and modify rules without requiring deep technical knowledge.
167 | - **API support**: Ensure that filtering rules can also be managed via APIs, enabling automation and integration with other systems or workflows.
168 | - **Performance considerations**: Implement efficient filtering mechanisms to ensure that the filtering process does not negatively impact the performance of event delivery.
169 | - **Logging and monitoring**: Provide logging and monitoring capabilities to track the application of filtering rules, including which events were filtered out and which were delivered. This information can help developers understand the impact of their filtering rules and diagnose any issues.
170 |
171 | **Examples:**
172 |
173 | In Shopify, a filter is applied using the following syntax when performing the subscription:
174 |
175 | ```
176 | filter = "variants.price:>=10.00"
177 | ```
178 |
179 | In Hookdeck, a filter rule is applied to a payload in transit:
180 |
181 | ```json
182 | {
183 | "variants": {
184 | "price": {
185 | "$gte": 10
186 | }
187 | }
188 | }
189 | ```
190 |
191 | By supporting filtering based on payload content, the event destination implementation can offer greater control and customization for event delivery, allowing developers to ensure that only relevant events are sent to their destinations.
192 |
193 | ## Feedback
194 |
195 | See [CONTRIBUTING](CONTRIBUTING.md) for more details on providing feedback and suggesting corrections and improvements.
196 |
--------------------------------------------------------------------------------
/website/src/components/Implementations.astro:
--------------------------------------------------------------------------------
1 |
Event Destinations in action
2 |
3 |
4 | A number of companies have inspired the Event Destinations Initiative and have
5 | an existing implementation.
6 |
160 |
207 |
208 |
209 | Outpost is self-hosted and open-source infrastructure that enables event
210 | producers to add Event Destinations to their platforms.
211 |
212 | Get started with Outpost ->
215 |