Deliver a signed payload to an endpoint - reach any system that accepts a webhook.
Connect one webhook endpoint by its URL and deliver payloads to it from an automation or an agent: a JSON object (or a raw body, for a receiver that wants form-encoded, XML or CSV) is POSTed verbatim and signed so the receiver can verify it came from yekar. Works with anything that accepts a webhook - Slack and Discord incoming webhooks, n8n, Make, a Zap, or a service the customer wrote. Delivery is one-way: a 2xx means the endpoint took the payload, not that it processed it. This SENDS webhooks; to receive one, give the automation an API trigger.
Connect
| Credential field | Required | Where it comes from |
|---|
Endpoint URL (ENDPOINT_URL) | Yes | The https delivery URL the receiver gave you. For most receivers it is the credential - anyone holding it can deliver - so it is stored encrypted and never reported back. |
Signing secret (SIGNING_SECRET) | No | Shared secret the receiver verifies the signature with. Optional: leave it empty for a receiver with no verification step. Standard Webhooks secrets keep their whsec_ prefix. |
Auth header value (AUTH_HEADER_VALUE) | No | Value sent in the auth header named above, e.g. “Bearer abc123”. Stored encrypted; never readable again. |
| Setting | Required | What it is |
|---|
Endpoint name (ENDPOINT_NAME) | No | What the receiver is called, e.g. “Billing service - invoice events”. Used to label runs and results. |
What it does (ENDPOINT_PURPOSE) | No | One or two lines describing what delivering to this endpoint causes. This is what an agent reads before deciding to send. |
Expected fields (EXPECTED_FIELDS) | No | Comma-separated payload keys the receiver reads, e.g. event, customerId, amount. |
Signature format (SIGNATURE_FORMAT) | No | One of: yekar (default - X-Yekar-Signature, the scheme Yekar.AI's own webhooks use), standard-webhooks (webhook-signature, per the Standard Webhooks spec), or none. Blank means yekar. Requires a signing secret; without one, deliveries are unsigned whatever this says. |
Auth header name (AUTH_HEADER_NAME) | No | Optional header the credential below rides in, e.g. Authorization or X-API-Key. Leave blank if the receiver authenticates by the URL or the signature alone. |
| Tool | Access | What it does |
|---|
Send webhook (yekar.webhook.send) | Write | POST a JSON payload to this connection's webhook endpoint. The object is delivered verbatim as the request body and signed with the connection's scheme when it has a signing secret. One-way: a 2xx means the receiver took the payload, not that it processed it. |
Send webhook with a raw body (yekar.webhook.send-raw) | Write | POST a raw body (form-encoded, XML, CSV, plain text) to this connection's webhook endpoint with an explicit content type, for a receiver that does not take JSON. Signed over the exact bytes sent, like Send webhook. |
Describe endpoint (yekar.webhook.describe-endpoint) | Read | What this connection delivers to and which fields the receiver expects, as its operator described them, plus what a delivery would actually carry - host, signature scheme, whether an auth header is sent. Reads the connection only; makes no request. A webhook endpoint is write-only, so this is the only way to learn what sending will do. |
Notes
- Paste the receiver's delivery URL. For most receivers that URL is the credential - anyone holding it can deliver - so it is stored encrypted and never appears in a result, an error or a log line.
- One connection = one endpoint. To reach several destinations, create one connection per destination and name each of them.
- The payload is delivered VERBATIM as the request body - nothing is added or renamed. That is what lets it drive a receiver with a fixed shape (a Slack incoming webhook wants {text}, Discord wants {content}). If the receiver branches on an event name, include that field yourself.
- Signing: leave the format blank and add a signing secret to get X-Yekar-Timestamp + X-Yekar-Signature (sha256 HMAC of “
<timestamp>.<body>”) - the same scheme Yekar.AI's run-completion webhooks use, so one verifier covers both. Set the format to standard-webhooks for webhook-id/webhook-timestamp/webhook-signature, verifiable with the Standard Webhooks libraries. Set it to none for a receiver with no verification step (Slack, Discord, a Zap).
- With no signing secret stored, deliveries go out UNSIGNED and every result says so - check “signatureFormat” before treating a delivery as authenticated.
- For a receiver that wants a token instead of (or as well as) a signature, set the auth header name (Authorization, X-API-Key…) and its value; it is sent on every delivery.
- Delivery is one-way. The result carries the receiver's status code and its delivery id - the handle to find this call in the receiver's own logs - and nothing about what the receiver then did. If an automation needs the outcome, have the receiver write it somewhere the automation can read.
- The endpoint must be a public https URL. Private, loopback and link-local addresses are refused, redirects are never followed (store the final URL), and a receiver that has not answered in 20s is treated as unavailable.
- Fill in the endpoint name, what it does and the expected fields. An endpoint tells us nothing about itself, so those properties are the only thing Describe endpoint - and therefore an agent deciding whether to deliver - has to go on.