Quickstart

The CLI is a single repost binary with the schema engine built in.

Copycurl -fsSL https://releases.repost.sh/cli/install.sh | sh
repost auth login

Copyrepost schema init

init asks which SDK language to generate and where the output should go, then scaffolds a repost/ directory:

Copyrepost/
├── schema.repost   # your event definitions; starts with an example
├── .env            # REPOST_SEND_API_KEY and REPOST_TOKEN, empty for now
└── .gitignore      # keeps .env out of your repo

You'll fill in the two .env values in step 5.

Open repost/schema.repost. A schema has three parts: a payload model, an event-type catalog, and an event that ties them together.

Copymodel Order {
  id       String
  currency String
}
 
type Order {
  created
}
 
event OrderCreated {
  type      @type(Order.created)
  data      Order
  timestamp DateTime
}

This defines one event, order.created, carrying an Order payload and a timestamp. The schema language page covers every construct.

Copyrepost schema migrate dev --name init

migrate dev records the schema as a migration (committed to your repo and reviewable in git diff, like a database migration) and generates the typed client for the language you picked.

In the dashboard, create an environment. This is where your events go live, with its own registry, customers, and keys. Then open Settings → API Tokens inside it and create a token.

A token carries one or more scopes:

Select all three for this walkthrough. In production, give each system its own narrowly scoped token. The token value starts with rp_ and is shown once. Copy it into repost/.env as both values:

CopyREPOST_SEND_API_KEY="rp_..."
REPOST_TOKEN="rp_..."

Copyrepost schema migrate deploy

The CLI sends your committed migrations to the environment and prints the applied diff. order.created is now a live, versioned event type, visible under Event Types in the dashboard.

A customer is who you send to, identified by an externalId you choose. An endpoint is where their webhooks go. Creating an endpoint also creates the customer:

Copycurl -X POST https://api.repost.sh/v1/customers/acme/endpoints \
  -H "Authorization: Bearer $REPOST_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://acme.example.com/webhooks"}'

The 201 response contains the endpoint and its whsec_... signing secret, which is returned only this once. By default the endpoint subscribes to every event type ("subscriptions": ["*"]).

Copycurl -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" \
  -d '{
    "type": "order.created",
    "customerId": "acme",
    "data": { "id": "order-1001", "currency": "EUR" }
  }'

Copy{
  "id": "msg_01JZX3NV7Q9WD9F2M6K4T8RSAB",
  "type": "order.created",
  "customerId": "acme",
  "timestamp": "2026-07-17T12:00:00.000Z"
}

Run it twice. The second call returns the same message with an Idempotent-Replay: true header instead of publishing a duplicate. Idempotency works this way for every publish.

Open Messages in the environment to follow the message to its delivery, attempt by attempt. On the receiving end, the webhook arrives as a signed Standard Webhooks request:

CopyPOST /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"}}

If the endpoint is down, Repost retries for about a day before parking the delivery in the dead-letter queue.

Customers manage their own endpoints, secrets, and delivery logs in a hosted portal. Mint an access link:

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

Open the returned url. This is the customer portal, with your branding, and no customer account is required.