Team, API Keys & Webhooks

These three settings pages live under Admin → Settings and govern who can operate your project and how outside systems integrate with it. Team controls human access, API keys manage machine credentials for the public REST API, and Webhooks push your project's claim events out to your own infrastructure.

Team

Open Settings → Team to see everyone who can access your project's admin surface, their role, and whether they've accepted yet.

Inviting a teammate

Enter the teammate's email, pick a role, and click Send invite.

The invite emails the teammate a link to the admin dashboard. Email is best-effort: if the send fails, the membership is still created and the teammate can sign in to pick it up.

Roles

Every teammate holds exactly one role. Roles are ranked Owner > Admin > Member > Viewer, and you can only assign or modify roles strictly below your own.

Changing a role or removing someone

In the member list, change a teammate's role with the inline role selector, or click Remove to revoke their access immediately. A few guardrails apply:

• You can't change or remove yourself; a second Admin or the Owner has to do it. This prevents locking the project out of its last operator.
• You can't touch the Owner; that's a support-only operation.
• You can only act on teammates strictly below your own role, and you can't promote anyone to your own role or higher.

Every invite, role change and removal is written to the Audit Log.

API keys

API keys are intended to let scripts, backend services and CI call Onsend on your project's behalf without a human session. Open Settings → API keys (requires Admin) to mint and manage them.

When you mint a key, Onsend shows the full key (formatted onsend_<…>) once, and stores only a SHA-256 hash plus a short prefix (never the raw key). Keys can be revoked from the list (a soft-delete retained for audit), and a revoked or expired key stops authenticating immediately. The exact endpoints, auth header, rate limits and scopes are documented in the API Reference.

Webhooks

Webhooks push your project's events to a URL you control, so your own backend can react in real time. Open Settings → Webhooks (requires Admin) to register endpoints.

Register an endpoint

Click New webhook, enter the destination URL and a comma-separated list of events to subscribe to.

Save the signing secret

On creation Onsend returns an HMAC signing secret (formatted whsec_<…>) once. Copy it now, because you'll use it to verify that incoming deliveries genuinely came from Onsend. You can pause (toggle active), edit, or delete a webhook later from the list.

Event types

Webhook delivery is live for claim lifecycle events only:

Payload

Each delivery is a JSON POST. Claim events carry:

{
  "type": "claim.confirmed",
  "occurredAt": "2026-06-01T12:00:00.000Z",
  "receiptId": "rcpt_…",
  "tenantId": "…",
  "campaign": {
    "id": "…",
    "slug": "summer-airdrop",
    "name": "Summer Airdrop",
    "tokenSymbol": "ACME",
    "chain": "ETHEREUM"
  },
  "wallet": "0x…",
  "amount": "1000000000000000000",
  "txHash": "0x…",
  "status": "CONFIRMED"
}

amount is the raw on-chain token amount: a decimal string in base units, so divide by 10^decimals for the human value. type matches the x-vandergrid-event-type header.

Verifying the signature

Every delivery is a POST with a JSON body and these headers:

To verify, compute the HMAC-SHA256 of the raw request body with your secret and compare it (in constant time) to x-vandergrid-signature:

import { createHmac, timingSafeEqual } from "node:crypto";
 
function isValid(rawBody: string, signature: string, secret: string): boolean {
  const expected = createHmac("sha256", secret).update(rawBody, "utf8").digest("hex");
  if (expected.length !== signature.length) return false;
  return timingSafeEqual(Buffer.from(expected, "hex"), Buffer.from(signature, "hex"));
}

Delivery & retries

A successful delivery is any 2xx response. Onsend does not follow redirects, so your endpoint must respond directly. Anything else (a non-2xx, a timeout, a connection error) is treated as a failure and retried with exponential backoff:

After 8 failed attempts the delivery is marked given up and no longer retried. Make your receiver idempotent, since a delivery can legitimately arrive more than once (e.g. when your endpoint 2xx's but the connection drops before Onsend records it).

This page covers the dashboard surfaces. The full per-endpoint REST reference, covering every route, request shape, scope and event payload, is documented separately: see the API Reference.