Skip to main content
Receive YCloud events at a public endpoint and process them without losing or repeating business actions. Use HTTPS for production, preserve the raw request body, and verify each signature before accepting the event.

Register your endpoint

In the YCloud Console, open Developers > Webhook, select Add Endpoints, enter the Endpoints URL, select Events, and save with Confirm. You can also use POST /v2/webhookEndpoints; see Configure webhooks for the request and response.
  • You can configure up to 20 endpoints per account.
  • The URL must be publicly reachable and must not resolve to a private address.
  • The URL supports up to 500 characters; the optional description supports up to 400.
  • Save the returned signing secret securely.

Read the event request

For complete examples, see Webhook payloads.

Verify the signature

The YCloud-Signature header has the form t=TIMESTAMP,s=SIGNATURE. The timestamp is Unix time in seconds.
  1. Extract t and s from the header.
  2. Join the timestamp, a period, and the exact raw request body bytes.
  3. Compute HMAC-SHA256 with the endpoint’s signing secret.
  4. Compare the hexadecimal result using a constant-time comparison.
Do not serialize parsed JSON to reconstruct the body. Whitespace, key order, or Unicode escaping changes the signature input. The example below also uses a configurable five-minute timestamp tolerance to reduce replay risk. This tolerance is an application policy, not a YCloud retry deadline. Keep your server clock synchronized.

Accept before acknowledging

Persist the validated event to a durable queue or transactional inbox before returning 2xx. If storage is unavailable, return a failure so delivery can be retried. After durable acceptance, let your worker handle business-processing failures with its own retries. This Express handler uses an application-provided persistEvent operation. Implement it as an atomic insert keyed by event id; an already stored event must count as success. Do not mark an event as processed before its business transaction commits.

Java and Spring example

This Java 17 example applies the same verification and durable-acceptance order. Provide an EventInbox bean backed by a transactional store with a unique constraint on event ID. insertIfAbsent must commit the full event before it returns; duplicate IDs return successfully. Your worker can then process and mark stored events in its own transaction.
Do not use a separate “already processed” Redis write before queueing the event: if the enqueue fails after that write, a retry could be dropped. Use an atomic, durable inbox or a queue whose acceptance and duplicate handling are atomic.

Timing, retries, and suspension

Return a 2xx response promptly; aim for less than 6 seconds. Slow responses above 10 seconds can reduce delivery priority. Do not run slow business work inside the HTTP handler. For a non-2xx response or missing response, the default retry intervals are: YCloud stops retrying that event after the configured retry limit. With the default settings, a URL can be suspended for 3 minutes when it reaches 200 failures per minute or 10 minutes of summed failure time within a minute across concurrent requests. Requests are paused during suspension and resume afterward. Also monitor the endpoint’s status. A pending endpoint does not receive events; see endpoint configuration.

Verify your receiver

  • A valid signature and durably stored event return 2xx.
  • Modified bodies, malformed signatures, and stale timestamps are rejected.
  • A duplicate event is accepted without repeating its business action.
  • A storage outage returns a failure and allows redelivery.
  • Unknown event types do not crash the receiver.
  • Processing failures are retried by your worker after acceptance.
  • Secrets and complete customer payloads are not written to application logs.