# Webhook Payload Template Generator for ERP Events

> Source: https://netray.co/tools/webhook-payload-template-generator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Design a consistent JSON webhook payload for ERP events, with an idempotency id, versioning and signature header guidance.

## Category

developer

## Audience

- ERP developer
- Integration engineer
- Solution architect

## Tool

**Kind:** template

**Output:** code

**Language:** json

**Fields:**

#### Event type

**Key:** event_type

**Type:** text

**Default:** sales_order.shipped

#### Event id

**Key:** event_id

**Type:** text

**Default:** evt_01JB8Q2X9K

#### Occurred at (UTC)

**Key:** occurred

**Type:** text

**Default:** 2026-10-20T09:15:30Z

#### Source system

**Key:** source

**Type:** text

**Default:** erp-prod-us

#### Record id

**Key:** record_id

**Type:** text

**Default:** SO-100245

#### New status

**Key:** status

**Type:** text

**Default:** shipped

#### Previous status

**Key:** prev_status

**Type:** text

**Default:** picked

#### Tracking number

**Key:** tracking

**Type:** text

**Default:** 1Z999AA10123456784

#### Record URL

**Key:** api_url

**Type:** text

**Default:** https://erp.example.com/api/v1/sales-orders/SO-100245

**Blocks:**

#### Payload (HTTP POST body)

**Body:** {
  "id": "{{event_id}}",
  "type": "{{event_type}}",
  "version": "2026-10-01",
  "occurredAt": "{{occurred}}",
  "source": "{{source}}",
  "data": {
    "id": "{{record_id}}",
    "status": "{{status}}",
    "previousStatus": "{{prev_status}}",
    "trackingNumber": "{{tracking}}",
    "url": "{{api_url}}"
  }
}

#### Headers to send

**Body:** Content-Type: application/json
X-Webhook-Id: {{event_id}}
X-Webhook-Timestamp: {{occurred}}
X-Webhook-Signature: sha256=<hex HMAC of timestamp + "." + raw body using the shared secret>

#### Receiver rules

**Body:** 1. Verify the signature against the raw body before parsing.
2. Reject timestamps older than five minutes.
3. Store the event id and ignore duplicates.
4. Return 2xx quickly and process asynchronously.
5. Fetch the full record from data.url if you need more fields.

**Notes:** The header names and signature scheme here are a design pattern, not a standard. Match whatever your platform defines if you are consuming someone else's webhooks. Keep payloads small and put sensitive detail behind an authenticated fetch.

## Content

**Intro:** Webhooks let an ERP tell other systems or AI agents that something changed instead of being polled. A good payload is small, versioned, identifiable and verifiable. This generator produces one with matching headers and receiver rules.

**Sections:**

#### How to use it

**Body:** Name the event in noun.verb form, supply the record id and the fields that changed, and generate the body and headers. Use the output as the contract between the sender and every receiver. Share it with downstream teams, and have them implement the five receiver rules. Export it to Word or PDF to attach to an integration design document.

**Bullets:**

- Use a stable, unique event id
- Include a schema version in every payload
- Send the new and previous status for state changes

#### Design reasoning

**Body:** The event id supports idempotency, because delivery is usually at least once and receivers must tolerate duplicates. The occurredAt field and a signed timestamp defend against replay. An HMAC signature over the raw body proves the sender knows the secret. A version field lets you evolve fields without breaking consumers. A url to the record keeps the payload thin, since ERP records can be large and sensitive.

#### Using webhooks with AI agents

**Body:** An agent can subscribe to events such as a purchase order approval or a quality hold and then decide what to do, rather than polling every few minutes. Keep the action behind the same permission and approval rules as any other tool. The payload should carry ids and states, not free text from users, so that injected instructions in data fields cannot steer the model.

#### Common mistakes

**Body:** Frequent errors include missing event ids, parsing the body before checking the signature, doing long work before replying so the sender retries, ordering assumptions between events, and putting full records with personal or controlled data in the payload. Document retry behavior and what a receiver should do on repeated failure.

**Cta:** Netray builds event driven integrations and agents on ERP data. If you want a design review of your webhook contract, get in touch.

**Faq:**

#### Should the payload carry the full record?

**Answer:** Usually no. Send ids, the changed fields and a url. Receivers can fetch the full record with their own credentials, which keeps payloads small and avoids leaking data to endpoints that do not need it.

#### How do I handle duplicate deliveries?

**Answer:** Store the event id when you process it and skip any event you have already seen. Most webhook systems guarantee at least once delivery, so duplicates are normal.

#### What is the signature for?

**Answer:** It lets the receiver confirm the request came from the sender and was not changed. Compute an HMAC with a shared secret over the raw body and timestamp, then compare in constant time.

#### Is the header format a standard?

**Answer:** No. Names and schemes differ between vendors. This template is a sensible pattern; follow the documented format of any platform whose webhooks you consume.

## Search terms

webhook payload example json, webhook payload template, erp webhook design, webhook event schema, webhook signature header hmac, webhook idempotency key, order shipped webhook example, webhook payload best practices

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json