hubspot data hub code formatter & linter

HubSpot Data Hub custom code actions support javascript (node) and python. `event` carries `inputFields`, `object`, and `origin`. return data with either `callback({ outputFields })` (classic) or `return { outputFields }` (modern). python uses `def main(event)` and returns `{ outputFields }`. import JS libraries via `require` (e.g. `@hubspot/api-client`, `axios`); access secrets via `process.env`.

javascripthubspot data hub
input
const email=event.inputFields.email
callback({outputFields:{email:email}})
output
format your own hubspot data hub code →free, no signup, runs in your browser

working inside hubspot data hub? the codefmt Chrome and Firefox extension adds a right-click Fix with codefmt in the code editor, so you format and lint in place without copy-pasting in and out of this page.

hubspot custom code globals

HubSpot Data Hub custom code actions let you run javascript or python in your workflows. the javascript runtime exposes event (trigger data with inputFields, object, and origin), callback (for callback-style output), process (for process.env secrets), and console. libraries like @hubspot/api-client and axios are preinstalled and loaded via require().

callback and return styles

HubSpot supports two code styles. the classic callback style uses exports.main = async (event, callback) => {} and returns data via callback(). the modern return style uses exports.main = async (event) => {} and returns data directly with a return statement. codefmt beautifies your code and handles both patterns, wrapping it in the correct structure before formatting and stripping it back.

linting hubspot code

codefmt declares the globals specific to HubSpot's Data Hub runtime (like event, callback, and process) so oxlint won't flag them as undefined. it runs general javascript lint rules, not HubSpot-specific semantic checks.

working on HubL templates instead of custom code actions? see the HubL formatter and linter.
working with HubSpot CMS templates? see the HubL linter.

frequently asked questions

how do I return data from a HubSpot custom code action?

HubSpot supports two styles. the classic callback style uses callback({ outputFields: { key: value } }) to return data. the modern return style lets you return { outputFields: { key: value } } straight from your main function, no callback parameter needed. codefmt handles both patterns correctly.

what is event.inputFields in HubSpot?

event.inputFields contains the data you configured in the workflow action settings. these are the custom properties you select when setting up the code action. you access them like event.inputFields.propertyName.

what is the difference between callback and return style in HubSpot custom code?

the callback style uses exports.main = async (event, callback) => {} and you call callback({ outputFields: {} }) to return data. the modern return style uses exports.main = async (event) => {} and you return the output directly with return { outputFields: {} }. the return style is cleaner and now fully supported by HubSpot. codefmt recognizes and formats both styles.

what globals are available in HubSpot custom code actions?

HubSpot custom code action javascript exposes event (trigger data with inputFields, object, and origin), callback (used with callback style to return data), process (for process.env secrets), and console. npm libraries like @hubspot/api-client, axios, and lodash are preinstalled and must be loaded via require(). they are NOT globals. codefmt recognizes the real globals and won't flag required modules as undefined.

does HubSpot support python custom code actions?

yes. HubSpot custom code actions now support python in addition to javascript. the python entrypoint is def main(event) where event exposes inputFields via event.get('inputFields'). requests and the @hubspot/api-client equivalents are preinstalled. codefmt formats HubSpot python with Ruff and wraps the code so return statements work correctly.

does codefmt catch common HubSpot custom code mistakes?

codefmt runs oxlint on your javascript, which catches general issues like unused variables and unreachable code, and it declares HubSpot's injected globals (event, callback, process) so they aren't flagged as undefined. it does not run HubSpot-specific checks. it won't catch a missing callback call or a bad event.inputFields access, since oxlint has no knowledge of HubSpot's runtime semantics.

primary source: HubSpot: Use custom code actions in workflows