Skip to main content

Event Notifications

Event Notifications is noon’s system for reliably delivering business events to partner-defined destinations.

Whenever something important happens inside noon (for example, an order or shipment update), an event is produced and pushed to the destinations you configure — automatically, reliably, and at scale.

You don’t need to poll noon APIs, build retry logic, or manage delivery infrastructure. Event Notifications handles all of that for you.

How This Works (Your Perspective)​

From a partner point of view, the flow is simple:

  1. You configure one or more destinations using the Event Notifications UI
  2. You subscribe those destinations to the event types you care about
  3. noon delivers events to your destinations whenever they occur

That’s it.

High-Level Flow​

  1. noon teams define and publish event types
  2. You create up to 5 destinations per project
  3. You subscribe destinations to specific event types
  4. When an event occurs, it is delivered to all subscribed destinations
  5. Delivery failures are retried and logged automatically

Core Concepts​

Destination​

A Destination represents a delivery endpoint owned by you.

Key characteristics:

  • Each project can have up to 5 destinations
  • A destination defines how events are delivered
  • Destinations are reusable across multiple event types
  • Destinations can be enabled, disabled, or updated independently

Event Notifications is destination-type agnostic by design. Multiple destination types may exist over time.

Currently supported destination type

  • HTTPS Webhook

    • A valid HTTPS URL
    • Optional credentials provided as key-value pairs

IP Allowlist​

noon delivers webhook events from the following public IPs. If your server enforces IP-based firewall rules, allowlist these addresses to ensure delivery:

IP Address
34.76.219.109
35.233.95.217
104.155.39.2

Event Type​

An Event Type represents a specific kind of business event produced by noon systems.

  • Naming format: EVENT_NAMESPACE::EVENT_TYPE
  • Example: FBPO::PO_SYNC

Important notes:

  • Event types are defined and owned by noon teams
  • Event Notifications does not validate payload schemas
  • Payload structure is defined by the producing team

Subscription​

A Subscription connects a destination to an event type.

  • When an event of that type occurs, it is delivered to all subscribed destinations
  • Delivery is handled independently per destination
  • Subscriptions determine what you receive and where it is delivered

Event Delivery​

Event Payload​

All events are delivered using a standard envelope, regardless of destination type.

{
  "event_schema_version": 1,
  "event_type": "FBPO::PO_SYNC",
  "metadata": {
    "message_id": "uuid",
    "destination_id": "string",
    "published_at": "timestamp",
    "project_code": "string"
  },
  "payload": {
    "... business payload defined by the producing team ..."
  }
}

What this means:

  • payload contains the business data
  • message_id uniquely identifies a message
  • metadata fields are stable and consistent across all events

Retry Policy​

Event Notifications automatically retries failed deliveries.

  • Up to 50 delivery attempts per message

  • Exponential backoff pattern:

    • Immediate first attempt
    • 2 min → 4 min → 8 min → 16 min → 32 min → 60 min
    • Maximum frequency: 1 attempt per hour

  • After the final attempt, the message is no longer retried

Important behavior to account for:

  • Events may be delivered more than once
  • Delivery may be delayed
  • At-least-once delivery semantics apply

Your system should be idempotent.

Final Notes​

Event Notifications is designed to be:

  • Push-based
  • Reliable
  • Observable
  • Easy to integrate with minimal operational burden

Once configured, it runs quietly in the background and delivers events as they happen.