postAt), a local datetime with a timezone (postAtLocal + timezone), or a relative delay from now (postIn).
UTC scheduling with postAt
Provide an RFC 3339 timestamp in UTC:
| Field | Description |
|---|---|
postAt | RFC 3339 timestamp in UTC (e.g., 2026-03-14T18:00:00Z). Timestamps in the past are delivered immediately. |
Local time scheduling with postAtLocal + timezone
When you need delivery at a specific clock time in a specific timezone, use postAtLocal and timezone together. Posthook converts the local time to UTC at scheduling time, accounting for DST.
| Field | Description |
|---|---|
postAtLocal | ISO 8601 local datetime without offset, in YYYY-MM-DDTHH:MM:SS format (e.g., 2026-03-15T13:00:00). Do not include a Z suffix or UTC offset. |
timezone | IANA Time Zone identifier (e.g., America/New_York, Europe/London, Asia/Tokyo). |
Relative delay with postIn
Schedule a hook relative to now using a duration string. Posthook resolves the delay to a UTC timestamp at scheduling time.
| Field | Description |
|---|---|
postIn | Duration string specifying how far in the future to deliver. Uses unit suffixes: d (days), h (hours), m (minutes), s (seconds). Compound values like 1d2h30m are supported. Minimum 1 second, maximum 365 days. |
30s, 5m, 2h, 7d, 1h30m, 1d2h30m45s
Validation rules
- Provide exactly one of
postAt,postAtLocal, orpostIn. timezoneis required withpostAtLocaland forbidden withpostAtorpostIn.
DST behavior
When usingpostAtLocal + timezone, Posthook resolves ambiguous times automatically:
- Spring forward (gap): If the local time falls in a skipped hour, delivery is shifted forward to the first valid moment after the gap (e.g.,
02:30becomes03:00). - Fall back (fold): If the local time occurs twice, the earlier occurrence is used.
Per-hook retry override
You can override your project’s default retry settings for individual hooks by including aretryOverride object. If omitted, the hook uses your project’s retry configuration.
Fields
| Field | Type | Required | Description |
|---|---|---|---|
minRetries | integer | Yes | Number of retry attempts (1–15) |
delaySecs | integer | Yes | Base delay between retries in seconds (5–60) |
strategy | string | Yes | fixed (constant delay) or exponential (increasing delay). Available strategies may vary by plan. |
backoffFactor | number | No | Multiplier for exponential backoff (1.1–4.0). Defaults to 2.0 if omitted. |
maxDelaySecs | integer | No | Maximum delay cap in seconds (60–3600). Required when strategy is exponential. |
jitter | boolean | No | Add random jitter to retry delays to avoid thundering herd |
Example: aggressive retries
Retry up to 15 times with a 5-second fixed delay:Example: exponential backoff
Start with a 10-second delay, doubling up to 5 minutes:Usage quota
Each plan includes a monthly hook quota — the number of hooks you can schedule per calendar month. EveryPOST /hooks call counts toward the quota, regardless of when the hook is scheduled to deliver. The quota resets at the start of each calendar month.
When you hit the limit, POST /hooks returns 429 Too Many Requests until the quota resets. Posthook sends email alerts at 75%, 100%, and 150% of your quota so you can adjust usage or upgrade before reaching the limit. Quota limits may vary by plan.
Quota headers
EveryPOST /hooks response includes headers showing your current plan usage:
| Header | Description |
|---|---|
Posthook-HookQuota-Limit | Maximum hooks allowed in the current calendar month |
Posthook-HookQuota-Usage | Hooks used so far in the current calendar month |
Posthook-HookQuota-Remaining | Hooks remaining in the current calendar month |
Posthook-HookQuota-Resets-At | RFC 3339 timestamp when the quota resets |