Skip to main content
This guide walks the whole system once: define an event in a schema, deploy it to an environment, publish it, watch it delivered, and give a customer their portal. You need the repost CLI, a Repost account, and curl. No SDK is required for the walkthrough; the last step shows where the typed clients pick up.
1

Install the CLI and sign in

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

Create a schema workspace

init asks which SDK language to generate and where the output should go, then scaffolds a repost/ directory:
You’ll fill in the two .env values in step 5.
3

Define your first event

Open repost/schema.repost. A schema has three parts: a payload model, an event-type catalog, and an event that ties them together.
repost/schema.repost
This defines one event, order.created, carrying an Order payload and a timestamp. The schema language page covers every construct.
4

Version it and generate the client

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.
5

Create an environment and a token

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:
repost/.env
6

Deploy your events

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.
7

Add a customer and an endpoint

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:
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": ["*"]).
No receiver handy? Create a bucket in the Ingest tab and use its URL. The delivered webhook, signed headers included, will show up in the bucket’s event history.
8

Publish your first event

202 Accepted
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.
9

Watch it deliver

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:
If the endpoint is down, Repost retries for about a day before parking the delivery in the dead-letter queue.
10

Give your customer the portal

Customers manage their own endpoints, secrets, and delivery logs in a hosted portal. Mint an access link:
Open the returned url. This is the customer portal, with your branding, and no customer account is required.

​
Where to go next

Defining events

Models, event types, defaults, and what each line generates.

SDKs

Replace the curl with a generated client in your language.

Delivery & retries

The retry schedule, the dead-letter queue, and replay.

Customization

Put your name and theme on the portal and event docs.