Celoxis Webhooks Explained: Real-Time Project Alerts, Setup, and Security

A project manager updates a task status in Celoxis. Somewhere else, a client is waiting to hear about it, a Slack channel should light up, or a billing system needs to know a milestone just closed. In a lot of organizations, that update still travels by someone remembering to send it. A copied message here, a manual export there, a “did you see this yet” ping.

That gap between something changing in your project system and everyone who needs to know finding out is where Celoxis webhooks come in. This guide covers exactly how they work: what they do, how to set one up, how the security model holds up, and what to check before you build anything on top of them.

If you already know you need real-time project alerts, skip to setting up your first webhook. If you are still comparing tools, start with what to evaluate.

What Celoxis Webhooks Actually Do

A Celoxis webhook is a standing instruction: when a specific activity happens in Celoxis, such as a project being created, a task changing status, or an expense getting approved, Celoxis sends that update automatically to a URL you specify. You choose which activities matter, provide an HTTPS endpoint, and Celoxis takes care of the rest. No one has to remember to pass the message along, because the system does it the moment the change happens.

This matters because the alternative, checking Celoxis repeatedly through the API to see if anything changed, is slow, wastes API calls, and still leaves a gap between the change and your team finding out about it. A webhook removes that gap.

Each delivery is a signed JSON POST. Your endpoint receives the event, confirms it came from Celoxis, and then does the work: notify a channel, create a CRM record, start a billing workflow, or push the change into a warehouse.

Why This Matters Right Now for CTOs and PMOs

Every PMO eventually hits the same wall: the project system holds the truth, but the truth needs to reach five other places. A CRM. A Slack channel. An accounting tool. A BI dashboard. None of those places check Celoxis on their own. Someone has to bridge that gap, and for a long time that someone was a person doing it by hand, or a script polling the API every sixty seconds hoping to catch something new.

Polling has a specific, quiet cost. You spend API calls asking “anything new?” and getting “no” the overwhelming majority of the time, until the one moment it matters, when your integration is still up to a minute behind reality. At the scale of a single project, that is tolerable. Across a full portfolio, it adds up to wasted infrastructure and a system that always feels one step behind.

There is a second, more specific problem that has been showing up across the project management software category. Several established platforms built their webhook systems as all-or-nothing: subscribe, and you get every event, every cell edit, every comment, every minor change, mixed in with the one signal you actually wanted. Teams ended up building their own filtering layer just to throw away most of what they received. Some vendors are now retrofitting event filtering into systems that originally shipped without it, which is a sign of how common this gap has been.

Celoxis webhook events are scoped by item type and action from the start. You subscribe to Project Add, Task Update, or Expense Delete independently. That avoids the retrofit entirely. More on how that works below.

How Celoxis Webhooks Work

The mechanism is simple by design. Three steps happen every time:

1. An activity happens in Celoxis. Someone creates a project, updates a task, logs time, or approves an expense.
2. Celoxis checks your subscription. If your webhook is set up to listen for that specific activity, it moves to step three. If not, nothing happens.
3. Celoxis POSTs a signed notification to your endpoint URL. Your system receives the update in near real time.

If the endpoint is down or returns an error, Celoxis does not drop the event. It retries automatically with backoff, and you can also retry a delivery by hand from the admin UI once the destination is healthy again. A delivery counts as successful when your endpoint returns an HTTP 2xx response.

Events you can subscribe to

Each webhook listens for Add, Update, and Delete actions on the item types you choose. You are not forced to take everything Celoxis can send. You pick what matters.

A few real examples of what this looks like in practice:

• A project gets created and a CRM deal appears automatically.
• A task gets added and the right Slack channel gets pinged without anyone typing a message.
• An expense gets approved and accounting is notified the same minute, not at the next batch sync.
• Time gets logged and a billing workflow kicks off on its own.

Start with one or two events, not all six. More events means more notifications landing on your endpoint, and most integrations only need a narrow slice of activity to do their job well.

What the payload looks like

Each delivery is a JSON array. Celoxis can batch several matching events into one POST, so your receiver should loop over the array rather than assuming a single object.

A typical modified-task event looks like this:

[
  {
    "type": "tasks.modified",
    "eventId": "<unique-event-id>",
    "occurredAt": "<UTC ISO timestamp>",
    "actor": {
      "value": 123,
      "text": "Alex Morgan"
    },
    "resource": {
      "type": "tasks",
      "id": 456,
      "text": "Prepare client kickoff deck",
      "url": "https://app.celoxis.com/..."
    },
    "changes": [
      {
        "field": "name",
        "label": "Name",
        "previous": {
          "value": "Draft kickoff deck",
          "text": "Draft kickoff deck"
        },
        "current": {
          "value": "Prepare client kickoff deck",
          "text": "Prepare client kickoff deck"
        }
      }
    ]
  }
]

A few details that save time during implementation:

• changes appears on Update events (*.modified). Add and Delete events do not include a field-by-field diff.
• Delete payloads keep the resource to type and id. The name and URL are omitted because the record is already gone.
• Expense approve or reject arrives as expenses.modified, not as a separate event type.
• Use eventId and X-Celoxis-Delivery-Id for logging and idempotency so a retry does not create a duplicate Slack message or a second invoice line.

Your endpoint should respond quickly with 200, 201, or 204. Do the heavy work after you acknowledge the request. If Celoxis cannot get a 2xx, the delivery stays pending and retries.

Setting Up Your First Webhook

Before you start, you need two things: administrator access with the Access to Webhooks permission, and an endpoint URL where Celoxis should send notifications. Use HTTPS in production.

1. Open the Webhooks page. From your profile menu, go to Admin, then Integrations, then Webhooks. If none exist yet, the list will be empty.
2. Click + Add. This opens the Add Webhook form.
3. Fill in the form.
   • Name: something clear, like “Notify Slack, New Tasks,” so anyone reviewing your webhooks later knows what it’s for
   • URL: your endpoint, entered carefully
   • Secret: click Generate Secret. Celoxis uses this to sign every notification it sends. Your receiving system uses the same secret to confirm the request is genuine. Generated secrets start with whsec_
   • Enabled: leave this on to start receiving notifications right away
   • Events: choose at least one activity from the list above
4. Save. Your webhook now appears under Your Webhook URLs.

From there, you can edit the name, URL, secret, or event selection at any time, disable a webhook temporarily without deleting it, or delete it permanently if you’re sure you won’t need it again.

One limit worth planning around: Celoxis allows up to five webhooks per company. Think through your integration needs before you start creating them one by one. If you need several downstream systems to react to the same events, point one webhook at an internal router or iPaaS and fan out from there, rather than burning a slot per destination.

If you update the endpoint URL, pending and failed deliveries are re-pointed to the new address. Already-delivered events are left unchanged.

Security: How Every Webhook Is Signed and Verified

This is the section most likely to matter to a CTO reviewing whether webhooks are safe to expose to an external endpoint, and it’s worth understanding properly rather than skimming.

Every request Celoxis sends includes three headers alongside the JSON body:

How the signature is generated

Celoxis joins the timestamp and the raw message body with a period, then runs that combined text through HMAC-SHA256 using your secret:

HMAC-SHA256(secret, “{timestamp}.{rawBody}”)

The result is sent as the v1= value in X-Celoxis-Signature. The same secret and the same message always produce the same signature, but there is no way to reverse the signature back into the secret itself.

How to verify it on your end

1. Use the message exactly as it arrives. Don’t reformat or rebuild it first, even a small change will break the match.
2. Pull the timestamp and signature out of the request headers.
3. Recreate the signature yourself using HMAC-SHA256 and your copy of the secret.
4. Compare the two. If they match, the request is genuine and you can accept it. If they don’t, reject it.

As a recommended extra step, reject any request where the timestamp is older than a few minutes, five is a reasonable default, so an intercepted message can’t be replayed later. Celoxis doesn’t require this, but it’s good practice.

Here’s a Node.js sketch of the same check:

const crypto = require("crypto");

function verifyCeloxisWebhook({ rawBody, timestamp, signatureHeader, secret }) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(`${timestamp}.${rawBody}`)
    .digest("hex");

  const actual = new URLSearchParams(
    signatureHeader.replace(/,/g, "&")
  ).get("v1");

  const ageSeconds = Math.abs(
    Date.now() / 1000 - Number(timestamp)
  );

  if (!actual || ageSeconds > 300) return false;

  return crypto.timingSafeEqual(
    Buffer.from(expected),
    Buffer.from(actual)
  );
}

Keep the secret private. Anyone who has it could construct fake requests that look legitimate. If you regenerate the secret, update it on the receiving side at the same time, or the old one stops working and every request starts failing verification. Both sides always need to match exactly.

Access Control: Who’s Allowed to Touch Webhooks

Webhooks are restricted to administrators, and even then, a role needs the specific Access to Webhooks permission before it can open the Webhooks page at all. Without it, users see a Permission Denied message.

The feature is also plan-gated. If Webhooks is not enabled on your plan, the menu will not appear. Contact your Celoxis administrator or Celoxis support if you expected to see it and don’t.

An administrator grants the permission from Main Menu, then Admin, then Settings, then Access Control, under the Company tab, by setting Access to Webhooks to Grant for the relevant role.

This matters more than it might first appear. Webhooks carry a secret and a live connection to external systems, and a misconfigured or careless integration can leak information or create noise fast. Celoxis’s own guidance is direct on this point: don’t give webhook access to client users. That’s a sensible default for any organization managing sensitive project or financial data across internal and external stakeholders.

Monitoring Deliveries and Handling Failures

Setting up a webhook isn’t the end of the job. Knowing whether it’s actually working is just as important, and Celoxis separates this into two views.

Recent Deliveries, found on the webhook’s detail page, shows the most recent pending and failed attempts. It’s built to help you spot problems quickly, not to be a full record. If it’s empty, that doesn’t mean nothing was sent. It means nothing pending or failed is sitting there right now. Successful deliveries live elsewhere.

View All opens the complete delivery history in a slide panel, including everything marked Delivered, Pending, or Failed. From there, clicking the eye icon on any row opens the full delivery detail in JSON, including status, number of attempts, the HTTP response code, and the exact payload Celoxis sent.

Delivery status breaks down into three states:

For anything pending or failed, fix the underlying issue first, a wrong URL or a receiving system that was down, then use Retry. Successful deliveries cannot be retried, which is the behavior you want: they already landed.

This in-product view is the difference between finding a broken integration yourself and hearing about it from a customer two weeks later.

Common Setup Problems and How to Fix Them

Most webhook issues trace back to a handful of causes. Here’s what tends to go wrong and how to resolve it.

Where This Fits in a Real PMO Stack

The use cases that show up most often follow a pattern: something changes in Celoxis, and a different system needs to react without a person in the middle.

• CRM sync: a new project triggers a corresponding deal or record automatically, so sales and delivery stay aligned without manual re-entry.
• Team notifications: task creation or status changes reach Slack or Teams the moment they happen, instead of surfacing in a status meeting two days later.
• Billing automation: logged time or an approved expense feeds directly into invoicing or payroll workflows.
• BI and reporting: project and task data streams into a warehouse or dashboard continuously, instead of relying on a nightly batch export that’s always a little stale.
• Cross-tool workflows: connecting Celoxis to Jira, Salesforce, ServiceNow, or an internal system built specifically for how your organization works.

None of these require custom polling scripts or scheduled jobs checking for changes. They require one webhook, scoped to the right events, pointed at the right endpoint.

What to Evaluate Before You Trust Any PM Tool’s Webhooks

If you’re comparing platforms, not just adopting whatever your PM tool happens to offer, a few questions separate a webhook system that holds up in production from one that becomes a maintenance burden six months in.

1. Can you subscribe to specific events, or only everything at once? Broad, unfiltered event streams mean you’re building your own filtering logic downstream, which is extra code to maintain and extra surface area for bugs.
2. Is every request signed, and is verification actually documented? A webhook without signature verification is an open door. Ask specifically how signing works, not just whether it exists. You want HMAC, a timestamp, and a delivery ID, not a shared header that anyone can copy.
3. Can you see delivery history, or are you flying blind? If a webhook silently fails for two weeks, you need a way to find out that isn’t “a customer mentions their integration seems broken.”
4. Is access to creating and managing webhooks actually restricted? Anyone with the ability to create a webhook can route sensitive project data somewhere external. That should sit behind a specific permission, not general admin access by default.
5. What’s the practical limit? A hard cap on webhooks per account is fine, but you need to know it exists before you’ve architected five different integrations around the assumption that you can create a sixth.

Celoxis answers those five questions in the admin UI: event-level filters, HMAC-SHA256 signing with timestamp and delivery ID, a built-in delivery history with a JSON payload viewer, a dedicated Access to Webhooks permission, and a published cap of five webhooks per company.

Celoxis vs. Other PM Tools on Real-Time Integration

Every platform in this category has webhooks in some form. Where they differ is in granularity, security defaults, and how much visibility you get once something is running. This comparison is based on each vendor’s own public developer documentation as of writing.

A few things stand out here. Celoxis and Wrike both support account or company-wide event filtering without requiring a separate webhook per board, which monday.com currently requires. Celoxis is also one of the few in this set where signature verification, delivery monitoring, and permission control are all built into the base admin experience rather than requiring an API call or a third-party tool to check on. Asana and monday.com lean more on developer-facing tooling than an in-product view, which works fine for a dedicated engineering team but adds friction if your PMO wants visibility without looping in IT for every check.

No platform here is objectively “best” across every row. If your team is API-first and already has strong engineering support, Asana’s model is workable. If you need broad, native visibility without building a separate monitoring layer, Celoxis’s built-in delivery view is the more direct path.

The Bottom Line

Webhooks solve a specific, recurring problem: keeping systems in sync without a person or a slow polling script standing in the middle. Celoxis webhooks give you event-level control from the start, a documented HMAC-SHA256 verification process, and a delivery monitoring view built into the admin panel rather than bolted on separately.

Whether that’s the right fit depends on what you’re connecting Celoxis to, how much engineering support you have on hand to build and maintain the receiving side, and how many integrations you realistically need to run at once.

If you’re weighing this against your current stack, the setup steps above take a few minutes to test end to end, which is usually enough to tell you whether it fits.

Setting up your first webhook takes about ten minutes if your endpoint is ready to go, and it’s a good way to see the actual payloads before committing to a bigger integration. If you’d rather see the whole flow walked through on your own project data, book a Celoxis demo or start a free trial and try it there.