Can I send several events in one request?

Renta stores each request as one row, so an array in the body stays a single row with the whole array inside body . To get a row per event, send one event per request.

When do events appear in the destination table?

The webhook URL accepts events around the clock, and Renta keeps them in an internal buffer for 30 days. The pipeline moves them to the warehouse on its schedule, so an event appears in the table after the next run that covers its receive date.

What happens if my system retries the same webhook?

Every received request gets its own Event ID and becomes a separate row. Renta cannot tell a retry from a new event, so deduplicate such rows in the warehouse by a key from your payload, such as an order ID.

Can I load events that were sent before the connection was created?

No. The table starts with the first event your webhook URL receives. Renta has no way to import requests that were delivered to other systems earlier.

Webhooks

Renta loads the events your systems send to a personal webhook URL into your data warehouse, one table row per received request.

Authentication

The Webhooks source needs no external credentials. You create a connection, and Renta issues a URL that accepts events.

Webhook ingestion runs under an SLA with 99.9% guaranteed availability.

Connect Webhooks source

Follow these steps to create a Webhooks connection and get your event URL.

Go to the CatalogStep 1

Navigate to the Connections > Catalog section in the left sidebar.
Open the Event stream category and click the Webhooks card marked Source.

The category contains two Webhooks cards. The one marked Destination is a different connector. It sends events out of Renta to your own endpoint.

Webhooks Source card in the Event stream category of the Renta catalog

Fill in the connection formStep 2

In the Source name field, specify a name for this data source. It is used exclusively in the Renta interface.
Open the Authorization type dropdown.

Add a new Webhooks connection page with the Source name field and the Authorization type dropdown

Choose the authorization typeStep 3

No authorization.
The URL accepts events without additional credentials. The URL itself is hard to guess because it contains two long identifiers.
Custom token.
Renta also stores a token value that you define for this connection.

Authorization type dropdown with the No authorization and Custom token options

Save the connectionStep 4

If you picked Custom token, enter its value in the Custom token field that appears below the dropdown. Then click Save.

Webhooks connection form with the Custom token field filled in and the Save button

Source createdStep 5

The new source appears in the Sources list with the Active status. You can now copy its URL and use it in pipelines.

Sources list with the new Webhooks source in the Active status

Webhook URL

Open the connection in the Sources list to get the address your systems will send events to. The Webhook URL field shows the personal URL of this connection. Copy it with the button on the right.

Point your system at this URL wherever it lets you configure an outgoing webhook. The URL accepts POST requests with a JSON body:

curl -X POST "<your Webhook URL>" \
  -H "Content-Type: application/json" \
  -d '{"event": "order_created", "order_id": 1024, "total": 99.90}'

Renta replies at once and stores the event in the background:

{"is_success": true, "event_id": "550e8400-e29b-41d4-a716-446655440000"}

The event_id from the response is the same value the Event ID column gets in the destination table, so you can trace any request down to its row.

Format details:

Besides JSON, the URL accepts application/x-www-form-urlencoded bodies. Renta converts form fields to JSON before storing them.
A request whose body is not valid JSON or form data gets a 400 response and is not stored.
One request always becomes one row. A JSON array in the body is not expanded into multiple rows.

Renta receives all incoming webhooks on its own ingest service. The service is built for high load and handles billions of events, so you do not need to throttle senders on your side.

Received events stay in Renta for 30 days. If a pipeline breaks or loads the wrong fields, you have 30 days to fix it and reload the affected days.

Create a pipeline

Once the source is created, build a pipeline to move the received events into your destination.

Create a Webhooks pipeline

Link your Webhooks source to a destination and configure the pipeline.

Select Webhooks as the sourceStep 1

In the left sidebar, click New pipeline. On the Source step, select Webhooks under Already connected and click Next step.

Select a source step with Webhooks under Already connected

Select your Webhooks connectionStep 2

Choose the Webhooks connection you created earlier and click Next step.

Select your Webhooks connection step with the connection card

Select a destinationStep 3

On the Destination step, select your destination (for example, Google BigQuery) and click Next step.

Select a destination step with Google BigQuery under Already connected

Select the destination connectionStep 4

Choose the destination connection you want to load events into and click Next step.

Select your Google BigQuery connection step

Pipeline configuration

On the final step, pick the event fields, name the table, set the period, and define the schedule.

Parameters

Tick the fields that become columns of the destination table.

Field	Description
Event ID	The unique identifier Renta assigned to the event on receipt. Matches the event_id from the webhook response.
Timestamp	The date and time when Renta received the event, in UTC.
Body	The raw body of the request as a JSON string.
Date	The date when Renta received the event. Partitions the destination table and drives incremental loading.

The structure of your payload stays inside body. Extract the keys you need with the JSON functions of your warehouse.

Keep Date selected. Without it Renta cannot partition the destination table, and every run reloads the entire date range instead of only the recent days.

Table name

Name the pipeline and the destination table.

Integration name.
The name of the pipeline. It is used exclusively in the Renta interface.
Table name.
The destination table name. You can keep the auto-generated name or enter your own.

Date range

Set the period the pipeline covers. The range filters events by the date Renta received them.

Date start.
The first date of the period.
Date end.
The last date of the period. Keep Today so that the end of the period advances with every run.

The history starts on the day your webhook URL received its first event. Renta keeps received events for 30 days, so a run loads only the days inside this window.

Overwrite period

Events keep arriving after a run finishes. The overwrite window makes the next run reload the recent days, so the rows received in between land in the table.

Choose how many recent days each run reloads. The default Last 1 day covers the events received since the previous daily run.

Schedule

Choose how often the pipeline runs.

Schedule type	Description
Manual	The pipeline runs only when triggered manually through the interface or via API.
Daily	The pipeline runs once a day at the specified update time.
Interval	The pipeline runs at specified time intervals.
Cron expression	The pipeline runs on a schedule defined by a cron expression.

For Daily schedules, set the Update time, the exact time each run starts, then click Create pipeline.

Update time selection and the Create pipeline button

Renta also supports API triggers and integration with external orchestrators such as Apache Airflow, Dagster, and Prefect. See the full scheduling documentation for details.

The new pipeline appears in the Pipelines section under the ETL tab, where you can monitor its runs, progress, and the destination table name.

Pipelines list with the new Webhooks integration in the Completed status

Sync strategy

The load strategy depends on whether the Date parameter is selected.

Strategy	Supported report types	Description
Incremental	Webhook events (with the Date parameter selected)	The destination table is partitioned by date. Each run reloads the days inside the overwrite window, from the previous run date minus the overwrite period through the end date, and replaces the matching partitions. Earlier days stay untouched.
Full reload	Webhook events (without the Date parameter)	Without a date column the table cannot be partitioned, so every run reads the whole selected date range and replaces the table contents.

Frequently asked questions

Ready to get started?

Build your data pipeline today or get a personalized demo. Start free!

Need help?

Get expert support to ensure your project succeeds. We're here to help!

Feature requests?

Help shape our product! Share your ideas for new features and integrations.