v2.36.0
Release date: February 27, 2026
New features
Event Retry Endpoints
New endpoints for retrying failed event deliveries have been added for both effects and bridges:
POST /effects/:id/events/retry— retry failed effect event deliveriesPOST /bridges/:id/events/retry— retry failed bridge event deliveries
These endpoints require the retry-event access action.
When to Use
Use this feature when:
- Event deliveries have failed and exhausted all retry attempts
- The target service (webhook endpoint or bridge) was temporarily unavailable or experiencing issues
- You have fixed issues on the target service and want to resume event deliveries immediately
- You need to reprocess events from a specific time window
How It Works
When you retry events, the ledger will:
- Cancel all scheduled delivery jobs that are in a failed or pending state
- Reschedule them with no delay for immediate processing
- Resume event deliveries to the configured endpoint
You can specify an maxAge parameter (in minutes) to limit retries to events whose last delivery attempt was created within the past N minutes (default: 60, max: 48 hours enforced server-side).
Note that the last delivery attempt can be, e.g. 50 minutes ago, but for an event that was generated further back in time than that.
Set maxAge to 0 to retry all events regardless of age.
API Usage
REST API:
POST /v2/effects/{effect-handle}/events/retry
Content-Type: application/json
{
"data": {
"maxAge": 60
},
"hash": "...",
"meta": {...}
}Node.js SDK:
const { effect } = await sdk.effect
.with('my-effect-handle')
.events.retry({
maxAge: 60
})
.hash()
.sign([{ keyPair }])
.send()CLI:
minka effect events retry my-effect-handleThe CLI will prompt you for the offset value (default: 60 minutes) and guide you through signer selection and confirmation.
Response
The endpoint returns a 202 Accepted status, indicating that the retry request has been accepted and will be processed asynchronously.
Backward Compatibility
The legacy POST /effects/:id/activate and POST /bridges/:id/activate endpoints are kept for backward compatibility. They follow the same behaviour but require the activate access action instead of retry-event.
Improvements
- [docs] Added docs on how to verify hash and signatures from ledger
- [ledger] Added a limit to the amount of proofs any record can have in its
metafield. Safeguards the system against memory allocation issues. Currently defaults to 100 proofs.