HubSpot's objectless custom events, released in the Fall 2026 Spotlight developer changelog, let you fire a custom event via webhook or API without tying it to a contact, deal, ticket, or any other CRM record. That matters for Docusign Workflow Builder automation because it means a trigger no longer has to originate from a CRM object changing state - a deploy notification, a report completion, or an external alert can now fire the same way a deal-stage change does.

What are HubSpot's objectless custom events? #

Objectless custom events are HubSpot custom events defined with primaryObject set to "NO_OBJECT" instead of CONTACT, COMPANY, DEAL, TICKET, or a custom object. According to HubSpot's own changelog entry, the feature is built for "immediate automated routing through HubSpot for external or stack-wide signals" - the changelog lists product deploys, BI report completions, weather alerts, and external signals like FDA approvals as example triggers.

Before this release, every custom event definition required an associated object. HubSpot's event definition API now documents NO_OBJECT as a valid primaryObject value, and the send-occurrence endpoint explicitly says an objectId is "required unless the event definition's primaryObject is set to NO_OBJECT." That single API change is what unlocks everything downstream.

How do objectless custom events change what can trigger a webhook? #

Previously, a webhook-based custom event in HubSpot needed a record to attach to. If you wanted a deploy pipeline or a monitoring tool to kick off a HubSpot automation, you had to fake an association - attaching the event to a dummy contact, or routing it through a workaround object just so the event definition would accept it.

HubSpot's custom events documentation now walks through creating an objectless event directly in the webhook setup flow, and notes that once an event is created as objectless, you can't later associate it with a CRM object. That's a one-way door worth knowing before you build around it - decide at definition time whether the event is tied to a record or not.

Practically, this means any external system that can POST a webhook, or call the events API, can now fire a HubSpot workflow without first creating or looking up a contact, deal, or ticket. That's the same shape of trigger Baton already handles for HubSpot's object-based webhook actions - HubSpot fires, Baton receives, Baton forwards to Docusign Workflow Builder. The difference now is what's inside the payload.

Can an objectless HubSpot event trigger a Docusign Workflow Builder workflow? #

Yes, with a caveat on payload shape. HubSpot's webhook action in a workflow sends an HTTP POST to a URL you control, regardless of whether the triggering event is tied to an object or not. Baton listens on that URL, verifies the request's HMAC signature, and matches the fields in the payload to the parameters defined on a Docusign Workflow Builder workflow. Baton's HubSpot integration is already live in production (not in the research tier it started in), so the plumbing for receiving HubSpot webhooks is proven.

What changes is that an objectless event's payload has no objectId, no contact email, and no deal name to hand to Workflow Builder unless you explicitly put that data into the event's custom properties yourself. Workflow Builder still runs on whatever fields you send - it just can't infer a HubSpot record from an event that was never tied to one.

What does an objectless custom event payload look like compared to an object-based one? #

An object-based custom event occurrence, sent against a contact, typically looks like this:

{
  "eventName": "pe12345678_deal_funding_approved",
  "objectId": "501234567",
  "occurredAt": "2026-11-04T18:22:00Z",
  "properties": {
    "approved_amount": "48000",
    "approver": "jordan@acme.com"
  }
}

An objectless event occurrence, defined with primaryObject: "NO_OBJECT", drops the objectId entirely:

{
  "eventName": "pe12345678_deploy_completed",
  "occurredAt": "2026-11-04T18:22:00Z",
  "properties": {
    "service": "billing-api",
    "version": "2026.11.2",
    "environment": "production"
  }
}

If a Workflow Builder workflow's trigger expects a field called objectId or contact_record_id - because it was built against HubSpot's object-based payloads - that field simply won't be present in the objectless version. The workflow either needs a different trigger parameter set, or the properties you define on the objectless event need to carry whatever identifier Workflow Builder actually requires (a customer ID, an account email, a contract reference).

How do you wire an objectless HubSpot event to Workflow Builder through Baton? #

  1. Define the event as objectless in HubSpot. In Data Management > Event Management, create the custom event, choose "Setup webhooks" as the creation method, and select the objectless option per HubSpot's custom events guide. Remember this choice is permanent for that event definition.
  2. Decide what identifies the Docusign side of the workflow. Since there's no HubSpot record to anchor to, pick a property that your Workflow Builder workflow can use as a lookup key - a customer account ID, a signer email, a contract number - and make sure your source system includes it in every event's properties payload.
  3. Point the webhook at your Baton endpoint. Use the webhook URL Baton gives you for that workflow, the same way you would for any other HubSpot webhook action.
  4. Build the Workflow Builder trigger to expect exactly those property names. Baton forwards whatever fields arrive in the payload and matches them to the workflow's parameter names automatically - there's no intermediate mapping step to fix a mismatch after the fact.
  5. Test with a real objectless occurrence, not a simulated object-based one, before relying on it in production. The payload shapes are different enough that a test built on the old assumption will pass locally and fail in production.

If you haven't wired HubSpot into Baton before, the HubSpot webhook automation walkthrough covers the endpoint setup and HMAC verification basics this builds on.

What breaks if your Workflow Builder parameters expect an object ID that isn't there? #

The most common failure is a Workflow Builder workflow that was originally built against a HubSpot deal or contact trigger, then reused for an objectless event without updating its expected parameters. The workflow run either fails to start, because a required parameter has no matching field in the payload, or it starts with a blank value for that parameter and produces a broken envelope - missing signer data, an empty contract reference, or a document generated with placeholder text.

This is a payload-shape problem, not a delivery problem. Docusign Connect and Baton both have their own failure domains for delivery - dropped webhooks, signature mismatches, timeouts - covered in detail in why Docusign webhooks fail silently. An objectless-event mismatch is different: the webhook arrives successfully, verifies successfully, and still produces a workflow run that's wrong, because the field the workflow expected was never in the payload to begin with. Checking the exact payload a run was triggered with - not just whether it ran - is the fastest way to catch this, and that's one of the first things to inspect when a Workflow Builder run doesn't do what you expected (see seeing the exact payload that triggered a run).

The fix is always at the definition layer: either add the missing identifier as a custom property on the objectless event, or keep the workflow's object-based trigger separate from any objectless one that feeds the same Docusign Workflow Builder workflow. Don't assume HubSpot will backfill an objectId you didn't ask for - once an event is objectless, HubSpot says plainly it stays that way.

What should you do next? #

Objectless custom events open a real new surface for Docusign Workflow Builder triggers - deploy events, BI alerts, and anything else in your stack that was never going to be a HubSpot contact or deal. Before you wire one up, map the exact properties your Workflow Builder workflow needs, and build the event definition around that, not around whatever HubSpot happened to send before. If you're already running HubSpot through Baton, read the HubSpot integration docs and wire up your first objectless trigger against a test workflow before pointing it at production.

FAQ #

Do objectless custom events replace HubSpot's object-based custom events? No. Object-based custom events still work exactly as before. Objectless events are a separate option you choose when defining the event, for cases where tying the event to a contact, deal, ticket, or custom object doesn't make sense.

Can I convert an existing object-based custom event into an objectless one? No. HubSpot's documentation states that once you create an objectless event, you can't associate it with a CRM object later, and the reverse isn't offered either - the object association is set once at definition time.

Does Baton need any special configuration to accept an objectless HubSpot webhook? No extra configuration on Baton's side. Baton verifies the HMAC signature and matches payload fields to Workflow Builder parameters by name regardless of whether the source event is object-based or objectless - what changes is which fields actually show up in the payload, which is on you to account for in the workflow's trigger parameters.

What HubSpot API field tells me an event is objectless? The event definition's primaryObject field is set to "NO_OBJECT", documented in HubSpot's custom events API reference. When you send an occurrence for that event, the objectId field is no longer required.

When did HubSpot release objectless custom events? HubSpot announced objectless custom events in the Fall 2026 Spotlight developer changelog, as part of Developer Platform Version 2026.09.