Webhooks and Event Driven Integration

Why events beat nightly syncs for connected systems

Many businesses connect systems with scheduled jobs: every hour or every night, one system asks another for everything that changed. That works until volume grows or someone needs the answer now. A paid order sits unshipped until the next sync, a closed deal waits a day to become a project, and API rate limits start to bite. Webhooks flip the direction, so the system where something happened tells the others right away. Tepia uses them wherever the source platform supports them.

Typical event flows Tepia builds include a Stripe payment that activates an account and posts to the accounting system, a Shopify order that creates a pick ticket in the warehouse app, a HubSpot deal moved to closed won that opens a project with tasks in your operations tool, and a Salesforce platform event that updates a customer’s mobile app. Each looks simple in a diagram. The real work is in what happens when delivery goes wrong.

Scheduled syncs still have a place. Older ERPs and on premise systems often expose no events, and data that changes once a month does not justify extra moving parts. Tepia frequently combines both: events for speed, plus a nightly reconciliation that catches anything missed. For simple cases, compare Zapier and custom integration first.

Failure modes Tepia designs every receiver for

Webhook providers promise at least once delivery, not exactly once, and not in order. Tepia plans for each failure explicitly:

None of these are rare. An integration that runs for a year will meet every row in this table, which is why Tepia builds the protections before the first event goes live.

The event backbone behind the endpoint

A webhook receiver should do very little: verify, record, enqueue, respond. Tepia keeps it that small and puts the real work behind a queue such as Amazon SQS, Amazon EventBridge, Azure Service Bus or Google Cloud Pub/Sub. Workers read from the queue, call the target systems and record the result against the event.

• Raw event store: every payload saved as received, so you can answer exactly what Stripe sent last Tuesday.
• Routing rules: one event can fan out to several targets, each with its own retry policy.
• Transactional outbox: when your own app emits events, they are written in the same database transaction as the change, so nothing is published for a change that rolled back.
• Monitoring: a dashboard of events per source, processing lag and failures, with alerts when a source goes quiet.

This backbone often grows into a shared integration layer for the whole company, described on our middleware development page. When users need the result on screen instantly, Tepia pairs it with the patterns on our real time applications page.

Sending webhooks from your own product

If you run a software product, your customers will eventually ask to be notified when something happens in it. Tepia builds outbound webhooks the way well regarded APIs do: a settings page where customers register endpoints and pick event types, a signing secret per endpoint that can be rotated, retries with exponential backoff, and automatic disabling after repeated failures with an email to the endpoint owner.

The feature customers value most is a delivery log. Showing each attempt, the response code and the payload, with a button to resend, turns many support tickets into self service because integrators can debug their own endpoints. Tepia also publishes an event catalog with sample payloads and versioning rules alongside your API, so integrators know what will change and when.

Security on the sending side mirrors the receiving side. Tepia signs each payload with an HMAC that includes a timestamp, sends only the identifiers and fields a subscriber needs, and lets customers fetch full records through the authenticated API when they want more. That keeps sensitive data out of logs on systems you do not control and makes a leaked endpoint far less useful to an attacker.

How Tepia approaches event driven integration

1. Discovery: a map of every system, which events each one emits or accepts, current sync jobs and where data goes stale. Deliverables are an Investigation Summary, an Interview Summary and User Stories such as finance seeing a Stripe refund in the ledger within minutes.
2. Design: event flow diagrams, a payload and naming standard, and wireframes for the monitoring dashboard and replay screen, guided by a design questionnaire and style guide.
3. Development and Testing: an Alpha against provider sandboxes and a Beta on live traffic in shadow mode, with test plans that inject duplicates, delays, bad signatures and outages.
4. Training: hands on sessions for your operations and IT staff on reading the event log, replaying failures and adding a new route.
5. Launch: cutover from scheduled jobs flow by flow, with reconciliation reports comparing old and new results, and support reps on hand for the first weeks.
6. Support: issue resolution, alert response, provider API version upgrades and feature requests for new event sources.

Typically Discovery takes 1 to 3 months, development and QA 2 to 6 months, and launch about a month. See our process or talk to Tepia about the systems you need to connect.

Frequently asked questions