HubSpot Custom Code Secrets: API Key Disappearing Act in Workflows

Running an e-commerce business today means juggling a lot of tools. From your storefront, whether you're using a free online store maker or a robust platform, to your CRM and customer service systems, seamless integration is key. When you bring HubSpot into the mix for CRM, sales, and marketing automation, custom code actions in workflows become incredibly powerful for connecting the dots. But what happens when those powerful custom actions hit a snag, especially when it involves something as critical as API keys?

We recently saw a fascinating, albeit frustrating, discussion unfold in the HubSpot Community about a developer struggling with exactly this: API keys seemingly vanishing at runtime within a custom code action. It’s a head-scratcher that many RevOps pros and marketers dabbling in integrations can relate to.

The Case of the Missing Secrets

The original poster in the community thread was trying to set up a custom code action in a HubSpot workflow to create Zendesk tickets from deals. A pretty standard and incredibly useful automation, right? They had their Zendesk API key stored securely as a secret in HubSpot, which is the correct way to handle sensitive credentials.

Here’s the kicker: after initial successful tests in their sandbox environment, and even one successful run in production, the workflow started failing. The error? A simple, yet infuriating, missing_[secret_name]. The API key, clearly visible and attached in the UI, just wasn't there at runtime. It’s like a magic trick you didn’t ask for!

The original poster tried deleting and recreating the action, re-adding the secrets, and even reverted to their original, working code. Nothing helped. The secret would work once, then disappear on subsequent runs with no code changes. They even used HubSpot’s AI assistant, Breeze, to help build and review the code, which reported no issues with the code itself.

Community Weighs In: Initial Thoughts

A community moderator jumped in, suggesting the original poster consult the Docs Assistant (HubSpot’s AI chatbot for developers) on the Custom Code Actions developer documentation. This is always a good first step for technical issues, as AI can often spot common pitfalls.

Another community member, an experienced developer, pointed towards how the secret value might be accessed or stored within the code. Was it a local or global variable issue? He asked for visibility into the code, which the original poster promptly provided:

// =========================
// Zendesk config
// =========================
const username = 'ADMINACCOUNT@EMAILDOMAIN.com/token';
const token = process.env.Zendesk_HubSpot_Sandbox;
const zendeskUrl = 'https://ZENDESKSUBDOMAIN.zendesk.com/api/v2/tickets.json';

// =========================
// Safe diagnostics
// =========================
console.log('Zendesk username:', username);
console.log('Zendesk secret exists:', !!token);

if (token) {
  console.log('Zendesk secret length:', token.length);

  const tokenPreview =
    token.length <= 8
      ? '***masked***'
      : `${token.slice(0, 4)}...${token.slice(-4)}`;

  console.log('Zendesk secret preview:', tokenPreview);
}

if (!token) {
  throw new Error('Missing Zendesk_HubSpot_Sandbox secret at runtime');
}

// Trim in case the secret was pasted with a trailing space/newline
const trimmedToken = token.trim();

console.log('Trimmed secret length:', trimmedToken.length);

// ... (rest of the code for building and sending request)

The code clearly shows an attempt to access the secret using process.env.Zendesk_HubSpot_Sandbox and includes diagnostic logging to check for its existence and integrity.

The original poster also shared insights from the Docs Assistant:

Total length of secret values: Not an issue, well below 1000 characters.
Variable re-use: Code was structured correctly, variables re-evaluated on every execution.
Secret name match: Confirmed the variable name in code matched the secret name exactly.
Error message: The AI confirmed the custom error message Zendesk secret exists: false meant the platform wasn't injecting the secret into process.env at runtime, despite the UI showing it attached.

The AI's next recommendation? Open a support ticket. The irony? HubSpot support had already redirected them to the community!

Here's a look at the Custom Code panel screenshot the original poster shared:

The Critical Diagnostic & The Core Problem

Following further advice to add more detailed diagnostics, the original poster implemented additional logging to pinpoint the exact failure point. The results were telling:

DIAG env var exists: false
DIAG env var type: undefined
error: Missing Zendesk_HubSpot_Sandbox secret at runtime

This confirmed the issue was happening at the very first step. The custom code runtime simply could not read process.env.Zendesk_HubSpot_Sandbox at all. The code never got past the line const token = process.env.Zendesk_HubSpot_Sandbox;. This wasn't a problem with the code's logic, but with the HubSpot platform's environment provisioning.

Even after deleting the entire workflow and secret, then restarting from scratch with new names, the same result occurred: it failed the very first time it ran. This strongly suggested a platform-level bug.

The Expert's Recommendation: Back to Basics

Given the diagnostics, the most practical advice came from one of the community experts: go back to absolute basics. Forget generating code via AI for a moment. Create the least complex custom code framework possible, and add just two lines:

One to get the secret value from the environment.
One to log that value (or its existence) to the console.

exports.main = async (event, callback) => {
  const mySecret = process.env.YOUR_SECRET_NAME;
  console.log('Secret exists:', !!mySecret);
  // Add more logging for length or masked preview if it exists
  callback({});
};

If this foundational test works 100% of the time, then you can slowly build your required functionality back up. If even this minimal setup fails, then you’ve almost certainly found a bug in the HubSpot platform itself.

This systematic approach helps isolate whether the problem lies with your specific code's complexity or a fundamental issue with how HubSpot provisions environment variables to custom code actions.

ESHOPMAN Team Comment

This discussion highlights the inherent fragility of custom code dependencies, especially when critical authentication secrets are involved. For e-commerce operations, reliable integration is paramount to avoid disruptions in customer service, order fulfillment, or data sync. While HubSpot's custom code actions offer flexibility, relying on them for core authentication can be risky if the underlying platform exhibits such inconsistencies. We'd generally advocate for robust, pre-built integrations or external middleware for critical data flows, ensuring secrets are handled in more controlled environments.

Beyond the Bug: What to Consider

If you find yourself in a similar situation, confirming a platform bug, what are your options? The original poster mentioned considering a webhook instead of custom code, but found it lacked the necessary JSON body customization. This is a common limitation when integrating complex systems or moving from a squarespace ecommerce website builder to a more custom setup.

Escalate with HubSpot Support: With clear diagnostics showing a platform issue, you have strong evidence for their engineering team.
External Middleware: For critical integrations, consider using an external serverless function (e.g., AWS Lambda, Google Cloud Functions) or an integration platform (like Zapier, Make.com, or Workato) that can reliably handle secrets and execute custom logic. This moves the sensitive part of the integration outside of HubSpot's custom code environment.
Re-evaluate Integration Strategy: For e-commerce platforms, whether it's a PrestaShop alternative or a custom build, the reliability of data flow into HubSpot is non-negotiable. If built-in custom code proves unreliable for core authentication, explore certified app integrations or develop a dedicated private app for a more robust connection.

This community exchange is a prime example of the power of shared knowledge, even when facing elusive technical challenges. While the ultimate resolution for the original poster is still pending, the methodical debugging process and expert advice provide a clear path forward for anyone encountering the mysterious case of disappearing HubSpot custom code secrets.