Getting Started

Concepts

The Quickstart had you create an Application, an Event Type, an Endpoint, and a Subscription without explaining what any of them actually are. Here's the full mental model — six objects, one flow.

Two sides of every integration

LobThat sits between you and your customers. Everything below is described from your side.

Publisher — you
The engineering team integrating LobThat to send webhooks to your own customers. Everything in your dashboard belongs to you as a Publisher.
Subscriber — your customer
The developer on the receiving end, whose server gets the HTTP POST. They own the Endpoint and (soon) manage it themselves via the Subscriber Portal.

The account hierarchy

Three levels of nesting, top to bottom. Everything else in this page lives inside an Application.

Org
Organization
Your account. Created once, automatically, when you sign up.
Env
Environment
A named slice of your org — typically sandbox and production. Applications live inside one Environment.
App
Application app_uid
One integration's container: its own Event Types, Endpoints, Subscriptions, API keys, and publish rate limit. Most of what you do day-to-day happens at this level.

Inside an Application

These five objects are what the Quickstart had you create, in the order they connect.

Event Type
A named category, e.g. order.created. Can carry a JSON Schema, so malformed payloads are rejected at publish time instead of discovered at delivery. Event Types can also be defined once at the org level and imported into multiple Applications as a shared template — useful when several Applications send the same kind of event.
Endpoint
A subscriber's URL. Each Endpoint gets its own HMAC signing secret, optional inbound auth (API key or Basic Auth you configure on their behalf), a per-endpoint rate limit, and its own circuit breaker — one endpoint failing repeatedly never affects deliveries to any other endpoint.
Subscription
The link between one Endpoint and one Event Type — this is what actually causes delivery. No Subscription, no delivery, even if the Event Type and Endpoint both exist. A Subscription can also target a wildcard (every Event Type in the Application) instead of one specific type.
Event
One published instance — a specific order.created with a specific payload. Written to PostgreSQL durably before any delivery is attempted, so a queue failure downstream never loses data.
Delivery Attempt
One HTTP POST of one Event to one Endpoint via one Subscription. An Event with 3 matching Subscriptions produces 3 independent delivery attempt chains — one endpoint's retries never block or affect another's.

How they connect at publish time

You publish an Event → matched against Subscriptions → one Delivery Attempt per matching Endpoint → retried on failure → Dead Letter after exhaustion
Dead Letter Messages are what a Delivery Attempt chain becomes once retries are exhausted (10 attempts, exponential backoff up to 24h) with no success. They're replayable from the dashboard once the underlying issue on the subscriber's end is fixed — see Dead Letter Queue for the full guide.
← Quickstart Event Schemas →