Set up and manage webhooks

Last updated: August 16, 2026

Webhooks are how Nash tells your backend when something happens — a delivery is created, picked up, completed, or hits a problem. You point Nash at a URL your systems own, subscribe it to the events you care about, and Nash posts each event to that URL as it fires.

You manage webhooks under Settings ▸ Connections ▸ Webhooks. The page subtitle reads Manage webhook endpoints and events.

Note

The Connections group is hidden for provider organizations, so webhooks only appear for operator orgs.

An embedded dashboard

The Webhooks page is an embedded dashboard provided by Nash's webhooks provider, shown inside the portal. Because it's a third-party surface, its exact layout and labels are set by that provider and may differ from what you see in a screenshot. This article describes the job you do there, not each button.

Note

If the dashboard doesn't load for your organization, a webhooks portal may not be provisioned yet — reach out to Nash.

What you do here

In the dashboard you:

  • Add an endpoint — a URL on your own backend that Nash will post events to.
  • Subscribe the endpoint to events — choose the delivery and order lifecycle events you want that endpoint to receive.
  • Watch delivery attempts — see each event Nash sent to your endpoint and whether it succeeded, and replay attempts that failed so your backend can process them again.

The dashboard is also where you retrieve the signing secret your backend uses to verify that an incoming request really came from Nash.

Event names, payloads, and verification

The catalog of event types, the payload schema for each event, and how to verify the signature on an incoming request all live in the developer docs — they're what your backend codes against. See https://docs.usenash.com.

Not the same as customer notifications or widgets

Webhooks are machine-to-machine: Nash calling your backend with event data. A few nearby things are different jobs:

  • Customer notifications are the tracking messages your end customers receive, configured under Tracking — see set up customer notifications. Those are customer-facing, not backend event delivery.
  • Embed credentials are the secret your backend swaps for a widget session — see manage embed credentials. That's a different Connections page and a different job.

Related