Skip to main content
Planting fulfilment batch webhooks notify your HTTPS receiver when a planting fulfilment batch identified by planting_fulfilment_batch_id advances among the approved environmental states. They are outbound signed deliveries, not Akhdar REST paths. Use Webhooks for the shared envelope, signature verification, delivery semantics, and HTTP response expectations. Planting fulfilment batch events follow the same rules.
Planting fulfilment batch list and detail operations are not part of the partner server-to-server API documented here. Webhook data remains planting_fulfilment_batch_id, partner_id, and status.

​
When this event fires

Akhdar delivers environmental.status.updated event version 2 when a planting fulfilment batch successfully advances among the approved environmental states: recorded → funding_pending → funded → planting_pending → planted → verified funded means the batch reached that environmental fulfilment status. It does not mean planted. Do not claim funded, planted, or verified to customers before that status is present. New deliveries use event version 2. Transaction-centric payload version 1 (transaction_id plus status) is retired for new deliveries. Implementing-entity details, evidence counts, tree quantities, and individual-tree data are not included in this webhook payload.

​
planting_fulfilment_batch_id

planting_fulfilment_batch_id is the Akhdar-generated planting fulfilment batch identifier. Store it when you receive the event so you can correlate later version 2 deliveries for the same batch. partner_id scopes the batch to your Partner. status is the batch’s current environmental fulfilment status.

​
Relationship to contribution reads

Contribution recovery remains the partner server-to-server read path:
  • GET {baseUrl}/v1/impact-transactions?partner_event_id=
  • GET {baseUrl}/v1/impact-transactions/{transaction_id}
See Recover a contribution. Confirmed contributions may include a read-only environmental_fulfilment object. status on that object is the linked planting batch status when a batch is assigned. planting_fulfilment_batch_id may be present on that object when assigned. Authoritative tree totals are not on this webhook or on environmental_fulfilment.

​
Events

​
Example payload

Required data fields: planting_fulfilment_batch_id, partner_id, and status.

​
X-Akhdar-Event-ID

X-Akhdar-Event-ID is the logical event identifier. It must equal envelope event_id. It is stable across retries and redelivery. Use it for idempotent processing. X-Akhdar-Delivery-ID identifies one delivery attempt and changes on retry.

​
Verify, deliver, and rotate

  1. Verify — Validate X-Akhdar-Signature using HMAC-SHA256 over X-Akhdar-Timestamp, ., and the raw request body. Enforce the five-minute timestamp window. See Webhooks. During an overlap window, current and previous signing secrets only (max two) may verify.
  2. Respond — Return any HTTP 2xx when you accept the event. No response body is required.
  3. Deduplicate — Delivery is at-least-once. Process idempotently using event_id / X-Akhdar-Event-ID. Retries reuse event_id and send a new delivery_id.
A duplicate environmental.status.updated for the same event_id must not change your stored outcome. Akhdar delivers this event to the same HTTPS receiver configured for your environment as the other approved webhook events. Webhook signing is separate from X-API-Key; API credential revocation does not by itself invalidate signature verification while the webhook secret remains valid.