Back to case studies

OrderTime Automation

OrderTime Webhook Receiver & Azure SQL Event Logger

FastAPI webhook service that validates operational payloads, applies controlled intake rules, writes append-only event logs, persists structured records to Azure SQL, and exposes health and download endpoints for later analysis.

FastAPIPydanticAzure SQLJSONCSVBasic AuthWebhook IntakeEvent Logging

Event logging command view

OrderTime Webhook Receiver

Webhook intake, validation, normalization, append-only logging, Azure SQL inserts, and download endpoints

event-ready
01

Receive

Webhook

02

Validate

Auth / Schema

03

Normalize

UTC / JSON

04

Persist

Logs / SQL

05

Serve

Health / Export

Service controls

FastAPI / SQL
Basic auth
Schema validation
UTC timestamps
Append-only logs
SQL inserts
Health checks

Event stream preview

JSON / CSV / SQL
TimestampEventSourceStatus
2026-06-14 08:00 UTCinventory_updatepartner-feedLogged
2026-06-14 08:02 UTCreceipt_postedwarehouse-apiInserted
2026-06-14 08:05 UTCprice_changepricing-serviceValidated
2026-06-14 08:07 UTCpayload_errorexternal-hookRejected

Operational outputs

Append-only Event LogAzure SQL RecordsJSON DownloadCSV DownloadHealth EndpointMonitoring Support
Webhook
Controlled intake endpoint
Append-only
Immutable event logging
SQL + Files
Structured event persistence

Business problem

External operational events needed a controlled API endpoint for logging and later analysis. Without a governed intake layer, event traffic can become inconsistent, harder to audit, and less useful for downstream troubleshooting or reporting.

The system needed a reliable receiver that could authenticate requests, validate payloads, preserve event history, and store structured records in a queryable data layer.

System built

Built webhook endpoints with basic auth, validation, normalization, UTC timestamps, append-only JSON and CSV logging, Azure SQL inserts, download endpoints, and health checks.

The result is an operational event service that does more than receive requests. It creates a usable, auditable event history that can support analysis, troubleshooting, and downstream reporting.

Event controls

Signals reviewed

The receiver checks authentication, payload structure, persistence status, export availability, and service readiness before treating an operational event as successfully captured.

Authorization status
Payload schema validation
Required field presence
UTC timestamp normalization
Event type classification
Append-only log write
Azure SQL insert status
Health endpoint readiness
JSON download availability
CSV download availability
Request error handling
Operational monitoring support

Webhook lifecycle

How it works

01

Receive

Accept operational events through a controlled webhook endpoint instead of scattered manual logging.

The API creates a single, reliable entry point for external event traffic so operational systems can post updates into one governed intake layer.

02

Validate

Check basic auth, validate payload structure, and reject malformed requests before persistence.

Validation keeps the event stream cleaner and prevents bad or incomplete payloads from entering reporting and downstream analysis.

03

Normalize

Apply schema rules, normalize fields, and stamp the event with UTC-based timing metadata.

Normalization turns webhook traffic into a more queryable operational record rather than a loose collection of raw request bodies.

04

Persist

Write append-only event logs and insert structured records into Azure SQL for later analysis.

This layer preserves auditability while also making the events usable for reporting, monitoring, and troubleshooting.

05

Serve

Expose health checks and download endpoints so teams can retrieve JSON or CSV event history when needed.

The result is not just event capture. It is an operational event service with usable outputs and support tooling.

System layers

What the receiver coordinates

Intake layer

Receives webhook requests through a controlled FastAPI endpoint instead of relying on ad hoc event capture.

Validation layer

Applies basic auth, payload validation, and field checks so only valid events reach persistence.

Persistence layer

Stores event records as append-only logs and structured SQL rows for auditability and reporting.

Access layer

Provides health, JSON, and CSV endpoints so event history can be reviewed, downloaded, and monitored.

Impact signals

What the service improved

Append-only event logging for operational traceability

Azure SQL persistence for downstream reporting and analysis

JSON and CSV download endpoints for support workflows

Basic-auth intake for controlled external event submission

Cleaner operational event history through validation and normalization

Operational value

Webhook traffic turned into structured event history

More reliable event capture

Moves external operational events into a dedicated intake service instead of leaving them scattered across disconnected files or systems.

Stronger auditability

Append-only logging and SQL inserts create a clearer historical trail for troubleshooting and downstream analysis.

Better downstream usability

Normalization and structured inserts make event data easier to query, report on, and integrate with analytics workflows.

Cleaner support path

Health checks and download endpoints make it easier to inspect, validate, and troubleshoot the webhook service over time.

Why this project matters

Operational APIs are stronger when intake, persistence, and observability are designed together.

This project is not just a webhook endpoint. It is a controlled operational event service. Authentication, validation, append-only logging, Azure SQL persistence, download access, and health monitoring all work together to make incoming events more reliable and more usable.

That matters because downstream analytics only become trustworthy when upstream event capture is governed, traceable, and easy to support.

Confidentiality note

Visuals and descriptions are sanitized conceptual representations. They do not expose private company data, customer records, credentials, raw exports, internal pricing, operational screenshots, webhook secrets, payload contents, or proprietary source files.