> ## Documentation Index > Fetch the complete documentation index at: https://repost.sh/docs/llms.txt > Use this file to discover all available pages before exploring further. # Core Concepts > The six ideas behind Repost Send: environments, event types, customers, endpoints, messages, and deliveries. Send is built on six ideas. This page explains each one and then follows a single event through all of them. ## Environment An environment is where your events live: production, staging, or however you split your stages. It holds the deployed event types, your customers and their endpoints, the API tokens, and the portal your customers see. Credentials are scoped to one environment, and each token carries only the scopes it needs. `publish` lets a service publish events, `manage` lets a backend administer customers and endpoints, and `schema:deploy` lets CI deploy the schema. A publishing service cannot touch endpoints, and CI cannot publish. Tokens are stored hashed and shown once, at creation. ## Event type An event type is one kind of event you send, such as `order.created` or `invoice.paid`. Each comes from a line in [your schema](/docs/send/schema) and is deployed into the environment with a version, a description, and a JSON Schema of its payload. The portal's catalog and your [public event docs](/docs/send/event-docs) render this registry directly, so there is no separate list of events to maintain. ## Customer A customer is who you send to. This is one of your customers, not a Repost user, and you identify them with an `externalId` you already have, such as an account id or an org slug. There is nothing to sync: [creating a customer is an idempotent upsert](/docs/send/endpoints), and creating an endpoint for an unknown id creates the customer along with it. ## Endpoint An endpoint is a URL a customer wants webhooks delivered to, together with what delivery needs to know: which event types it subscribes to (`["*"]` means all), its signing secrets, optional custom headers, and whether it is enabled or paused. A customer can have several. Endpoints are the same objects everywhere they appear: in the [management API](/docs/send/endpoints), in the dashboard, and in the customer's own [portal](/docs/send/portal). ## Message A message is one published event addressed to one customer, identified by an id like `msg_01JZX...`. When the publish API answers `202 Accepted`, the message exists durably and your request path is finished. Whatever happens with the customer's endpoints afterwards, it cannot slow your application down. ## Delivery A delivery is one message bound for one endpoint. A customer with two subscribed endpoints produces two deliveries for the same message, each with its own attempt history and status. A delivery succeeds on a `2xx` response, [retries for about a day](/docs/send/delivery) on anything else, and moves to the dead-letter queue if it never gets through. Every attempt is recorded with its status, latency, and a bounded slice of the response. ## The life of an event 1. Your application calls `repost.webhooks.order.created(...)`. The generated client shapes the payload from the schema, attaches an idempotency key, and publishes. Repost answers `202` with a message id. 2. The message fans out into one delivery per subscribed endpoint of that customer. If no endpoint subscribes to `order.created`, there are no deliveries, and publishing is still safe. 3. Each delivery is a `POST` of the [signed](/docs/send/signing) envelope, `{ type, timestamp, data }`, to the endpoint URL. A `2xx` completes it. 4. Failed deliveries retry on a backoff schedule for roughly 24 hours, then park in the dead-letter queue with their attempt logs. 5. You can follow messages and deliveries in the dashboard. Your customer sees the same deliveries live in their portal and can replay from the dead-letter queue themselves. The rest of this tab covers each stage in the order you'll meet it: [define your events](/docs/send/schema), [deploy them](/docs/send/deployments), [publish](/docs/send/sdks), [deliver](/docs/send/delivery), and [set up the portal](/docs/send/portal). ## Continue Run the whole flow in about ten minutes. Where event types come from. The retry schedule, statuses, and dead-letter queue in detail.