Repost Send

Repost Send is a complete webhook sending system you plug into your application. You publish events; Repost handles delivery, signing, retries, documentation, and your customers’ self-service. It consists of:

The schema: define each event’s shape once, in a file in your repo
SDKs: generated, type-safe publishing clients for TypeScript, Go, Python, Java, and Kotlin
Delivery: signed webhooks with automatic retries, a dead-letter queue, and replay
The customer portal: self-service endpoints, secrets, live delivery logs, and generated event docs

Why Repost Send

Webhooks are an API your customers build against, and they are usually shipped without types, versioning, or reliable documentation. The typical setup is a POST helper in a queue worker, a payload shaped by whatever the serializer produces, and an events page someone updates by hand. It works until a customer integrates against docs that no longer match production. Send avoids the problem by generating everything from the schema:

The SDK, the payloads, and the event docs come from the same file, so they cannot disagree
A payload that doesn’t match its event definition doesn’t compile
Schema changes are recorded as migrations, reviewed in pull requests, and checked in CI
Delivery comes with signatures, about a day of retries, a dead-letter queue, replay, and per-attempt logs
Customers manage their own endpoints, secrets, and delivery history in a hosted portal

When to use Send

Send is a good fit if you run a platform that delivers webhooks to many customers, if you want event docs and SDKs that stay current without maintenance, or if you would rather not operate retry queues, signing, and secret rotation yourself. It may not be what you need if you have a single internal consumer (a message queue is simpler), if you need full control over delivery infrastructure, or if you only receive webhooks. Receiving is Repost Ingest, the other half of this product.

How it works

1. Define your events

The schema describes your payload models and event types:

repost/schema.repost

generator sdk {
  language = "typescript"
}

model Order {
  id       String
  currency String
}

type Order {
  /// An order was placed
  created
}

event OrderCreated {
  type      @type(Order.created)
  data      Order
  timestamp DateTime
}

2. Version and deploy them

Schema changes are recorded as migrations and deployed to an environment:

repost schema migrate dev --name init
repost schema migrate deploy

Each deploy also rebuilds your public event docs and the portal’s event catalog.

3. Publish from your code

Generation produces a typed client with one method per event type. The HTTP API is available when you’d rather not use one:

import { createRepostClient } from "@repost/client";

const repost = createRepostClient();

await repost.webhooks.order.created({
  customerId: "acme",
  data: { id: "order-1001", currency: "EUR" },
  idempotencyKey: "order-1001-created",
});

client, err := repostclient.NewClient(repost.ClientOptions{})
if err != nil { log.Fatal(err) }

result, err := client.Webhooks.Order.Created(ctx, repostclient.OrderCreatedInput{
    CustomerID: "acme",
    Data:       order,
})

client = RepostClient()

result = client.webhooks.order.created(customer_id="acme", data=order)

curl -X POST https://api.repost.sh/v1/messages \
  -H "Authorization: Bearer $REPOST_SEND_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-1001-created" \
  -d '{"type": "order.created", "customerId": "acme", "data": {"id": "order-1001", "currency": "EUR"}}'

Every client behaves the same way: deterministic payloads, automatic retries, and an idempotency key that makes repeats safe.

4. Repost delivers

Each customer endpoint subscribed to the event receives a signed request. If the endpoint is down, Repost retries for about a day and then parks the delivery in a dead-letter queue for replay:

POST /webhooks HTTP/1.1
content-type: application/json
user-agent: Repost-Webhooks/1
webhook-id: msg_01JZX3NV7Q9WD9F2M6K4T8RSAB
webhook-timestamp: 1784289600
webhook-signature: v1,K5oZfzN95Z9UVu1EsPQqUIoRQOU...

{"type":"order.created","timestamp":"2026-07-17T12:00:00.000Z","data":{"id":"order-1001","currency":"EUR"}}

5. Your customers manage themselves

Mint a portal link from your backend. Your customer gets their endpoints, signing secrets, live delivery logs, and your event catalog, in your branding, with no account to create:

curl -X POST https://api.repost.sh/v1/customers/acme/portal-access \
  -H "Authorization: Bearer $REPOST_TOKEN" \
  -d '{}'

Next steps

Quickstart: run the whole flow yourself, from an empty directory
Core concepts: the six ideas behind everything above
Defining events: the schema language in full
Customer portal: what your customers get, and how they reach it

Send

Schema

Publishing

Delivery

Customer experience

TypeScript

Go

C#

Python

Java

Kotlin

Why Repost Send

When to use Send

How it works

1. Define your events

2. Version and deploy them

3. Publish from your code

4. Repost delivers

5. Your customers manage themselves

Next steps

​Why Repost Send

​When to use Send

​How it works

​1. Define your events

​2. Version and deploy them

​3. Publish from your code

​4. Repost delivers

​5. Your customers manage themselves

​Next steps

Why Repost Send

When to use Send

How it works

1. Define your events

2. Version and deploy them

3. Publish from your code

4. Repost delivers

5. Your customers manage themselves

Next steps