Core concepts

Understand the delivery model

Relayline accepts an event, queues a delivery to one HTTPS destination, and records every attempt until the delivery succeeds or exhausts its retries.

Base URL
https://api.relayline.example
API version
v1 in the request path
Data format
JSON over HTTPS

Resource model

The API separates the data you submit from the work required to deliver it. This makes delivery state and retries observable without changing the event payload.

Event

The named business occurrence and JSON payload you want to send, such as order.created.

Destination

The HTTPS endpoint that receives the event as a signed webhook request.

Delivery

The tracked attempt to send one event to one destination. Delivery IDs begin with dlv_.

Attempt

One HTTP request to the destination. A delivery can have up to five attempts.

Delivery lifecycle

A delivery moves through a small set of states. Treat delivered and failed as terminal.

  1. 1 · acceptedqueued

    The request is valid and waiting for its first attempt.

  2. 2 · temporary failureretrying

    An attempt failed and the next attempt is scheduled.

  3. 3a · successdelivered

    The destination returned a status from 200 through 299.

  4. 3b · exhaustedfailed

    All five attempts ended without a successful response.

Prevent duplicate deliveries

Set idempotency_key when creating a delivery. Keys are scoped to the authenticated project and retained for 24 hours.

  • Repeating the same key and request body returns the original delivery.
  • Repeating the key with different request data returns 409 Conflict.
  • Use a stable business identifier, such as order-7M2L9-created, rather than a random value generated for every retry.

Identifiers and timestamps

Identifiers are opaque strings. Store them exactly as returned and do not infer creation time or ordering from their value. Timestamps use RFC 3339 format in UTC, such as 2026-09-04T14:32:18Z.