Blog

Integrations

Integration posts collect provider-specific setup details, payload shapes, event types, and operational pitfalls for webhook producers such as Stripe, GitHub, Shopify, and internal platforms.

Use this section when you already know the provider you want to connect and need practical notes for receiving, verifying, routing, replaying, and operating that traffic through FastHook.

Integration Tracks

Each integration track will focus on a real provider workflow instead of a generic webhook checklist. The goal is to show which events matter, how signatures work, what a good destination contract looks like, and where retries or duplicate deliveries can surprise a production system.

  • Payments and billing providers where ordering, retries, and idempotency are critical.
  • Developer platforms where repository, workflow, issue, and deployment events need clean routing.
  • Commerce systems where order, customer, fulfillment, and inventory events may fan out to several services.
  • Internal service-to-service webhooks where teams need a shared gateway, audit trail, and replay workflow.

Provider Checklist

A FastHook integration usually starts with a source URL, then adds provider verification, one or more destinations, and operational controls around retries and replay. The provider-specific post should make those decisions explicit.

  • Create a dedicated source per provider environment, such as stripe-production or github-staging.
  • Record the headers the provider signs and decide whether verification belongs at the source, destination, or both.
  • Map the provider's important event types to destination branches instead of sending every event everywhere.
  • Decide which downstream services must be idempotent before enabling bulk replay or long retry windows.
  • Set destination throughput limits before replaying a large failed window into a fragile receiver.

Inbound And Outbound Shape

Provider notes should cover both sides of the route. The inbound side explains what FastHook receives from the provider. The outbound side explains what your destination receives after routing, transformation, retry, and replay decisions are applied.

Integration Shape
Provider webhook
  -> FastHook source URL
  -> optional provider signature verification
  -> connection filters and routing
  -> destination delivery
  -> attempts, retries, pause controls, and replay

Operational Questions

The most useful integration pages answer the questions that appear during incidents, not only the happy-path setup screen.

  • Which event types can safely be replayed, and which need extra receiver-side guards?
  • What does a duplicate event look like for this provider?
  • Which response codes should trigger provider retry versus FastHook retry?
  • How do you pause one downstream branch without losing newly received provider traffic?
  • Which metrics confirm that the provider is still sending traffic and the destination is still accepting it?

Planned Provider Notes

These are the first provider-specific pages planned for this section. Until they are published, the linked docs below cover the reusable FastHook pieces each integration will use.

  • Stripe billing webhooks for invoices, subscriptions, checkout sessions, and payment failures.
  • GitHub webhooks for repository events, workflow runs, pull requests, and deployment automation.
  • Shopify webhooks for orders, customers, products, fulfillment, and inventory changes.
  • Internal platform webhooks for service-to-service event delivery with audit and replay.

Next