Developer Webhooks

Developer webhooks let your application receive real-time events from Seev API products. Use them to fulfil orders, update internal records, notify customers, or reconcile transactions without polling.

How webhooks work

Your system triggers a Seev API event
  -> Seev sends a POST request to your webhook endpoint
  -> Your webhook handles the event and returns a response to Seev
  -> Seev saves the successful delivery or retries depending on your response

1. You create a webhook endpoint in the Developer Dashboard.
2. Your system performs an API action that triggers a Seev event.
3. Seev sends a POST request with the event payload to your endpoint URL.
4. Your webhook verifies and processes the event, then returns a response to Seev.
5. Seev records the delivery as successful when it receives a 2xx response, or marks it for retry when the response fails or times out.

Webhook endpoints

Create a webhook endpoint from Seev API -> Webhooks.

You will need:

Example endpoint URL:

https://api.example.com/webhooks/seev

Event types

Webhook event types are coming soon. We are still finalizing the event taxonomy for developer API products, so treat any event names shown in the dashboard UI as placeholders until this section is updated.

Webhook logs

The Webhook logs tab helps you inspect delivery attempts.

Use logs to debug failed deliveries, slow endpoints, or unexpected status codes.

Handling events

Your endpoint should:

1. Accept POST requests from Seev.
2. Verify the webhook signature when signing is available.
3. Process the event idempotently.
4. Return a 2xx response quickly.

Example handler shape:

export async function POST(req: Request) {
  const event = await req.json();

  // Store the event ID or transaction reference before taking action.
  // If you have already processed it, return a 2xx response.

  return Response.json({ received: true });
}

Signatures

When webhook signing is enabled, Seev includes a signature header with each request. Verify the signature before processing the event so your server can confirm the request came from Seev and was not tampered with.

If signature verification fails, log the attempt and ignore the event. Avoid triggering fulfilment, balance updates, customer notifications, or other side effects from unsigned or invalid webhook requests.

Retries and delivery

Seev may retry failed deliveries when your endpoint returns a non-2xx response or times out. Retry behavior is designed to help with temporary outages, slow handlers, or network issues.

The Webhook logs tab is the place to inspect delivery attempts, response times, HTTP status codes, and whether a delivery completed.

Best practices

• Respond quickly. Return a 2xx response as soon as you safely can, then process slower work asynchronously.
• Make handlers idempotent. Store a unique event ID or transaction reference before applying side effects.
• Verify signatures. Do not trust webhook payloads until signature verification is available and passing.
• Do not trust redirects alone. For payment fulfilment, rely on server-side verification and webhook delivery instead of only the customer's browser redirect.
• Log raw events. Keep enough event data to debug delivery issues and reconcile transactions later.

Related docs

• Developer Transactions
• Checkout API
• Idempotency