Claude custom projects in the automation workflow?

A common question in the r/ClaudeAI community cuts right to a real gap in the current Claude ecosystem: can you call Claude's "Projects" feature programmatically inside automation workflows like Make.com or n8n? The short answer is no — not directly, not yet. But the longer answer is what actually matters, because once you understand why Projects exist and what they're doing under the hood, you can replicate every meaningful benefit through the API with a little architecture work. I've built production AI agents on top of Claude (including Buddy, an open-source Google Ads agent), and this is exactly the kind of infrastructure question that separates hobby automations from systems that actually run in the background without you babysitting them.

What Claude Projects Actually Are (Under the Hood)

Before we solve the automation problem, it's worth being precise about what Claude Projects give you in the UI — because that shapes exactly what you need to replicate in code.

When you create a Project in Claude.ai, you're essentially getting three things bundled together:

• A persistent system prompt — instructions that apply to every conversation in that project without you typing them again
• Shared knowledge files — documents, PDFs, or text you upload that Claude can reference across all conversations in that project
• Conversation isolation — chats within a Project are scoped separately from your general Claude history

That's it. There's no magic. The UI is a wrapper around things the API already supports individually. The reason Make.com has no "Call Project" module is that Anthropic hasn't exposed Projects as a discrete API endpoint — likely because the feature is primarily a user-experience convenience layer, not a new model capability.

Replicating Claude Projects in Any Automation Tool

Here's the mental model that unlocks everything: instead of thinking "I need to call a Project," think "I need to recreate what a Project provides on every API call." The Claude Messages API lets you do exactly this.

Step 1: Move Your Project Instructions to a System Prompt

In the Claude.ai UI, you give your Project a set of instructions. In API calls — whether through Make.com, n8n, Zapier, or direct HTTP — you send those same instructions as the system parameter in your request body.

A basic Make.com HTTP module calling the Anthropic API looks like this in the request body:

{
  "model": "claude-opus-4-5",
  "max_tokens": 1024,
  "system": "You are a Google Ads specialist assistant. Your job is to analyze campaign performance data and suggest budget adjustments. Always output your recommendations as structured JSON. Never recommend increasing spend on campaigns with ROAS below 2.0.",
  "messages": [
    {
      "role": "user",
      "content": "{{Campaign performance data from previous step}}"
    }
  ]
}

That system parameter is your Project instructions. Store it in a Make.com Data Store, an n8n credential, a Google Sheet, or any persistent storage layer — and inject it into every call. You've now replicated the "persistent instructions" feature of Projects.

Step 2: Inject Document Context via the Messages Array

Projects let you upload files that Claude references across conversations. In the API, you pass that same content as part of the messages array — either as text in the user turn or using Claude's document support for PDFs and other file types.

For most marketing automation use cases, the practical approach is:

1. Store your reference documents in Google Drive, Notion, or a database
2. Add a step in your workflow to fetch the relevant document content
3. Inject that content into the system prompt or as an initial assistant/user message before your main task prompt

Step 3: Handle "Project Memory" with External Storage

This is where most people get tripped up. Projects in the Claude UI retain a thread of conversation history scoped to that Project. The API is stateless — it remembers nothing between calls unless you tell it to.

For automation workflows, this is actually an advantage once you set it up correctly. Your options:

For a Make.com workflow that needs to remember the last 5 interactions with Claude, you'd store the conversation array in a Data Store and prepend it to each new API call. Most practical automation workflows don't need more than 10–20 message turns in context — after that, you're burning tokens on history that rarely affects output quality.

Setting This Up in Make.com: A Practical Walkthrough

Since the r/ClaudeAI thread specifically mentions Make.com, let's walk through the actual module setup.

The HTTP Module Configuration

Make.com doesn't have a native Claude module that exposes Projects, but the generic HTTP module works perfectly. Here's the setup:

1. Method: POST
2. URL: https://api.anthropic.com/v1/messages
3. Headers:
   • x-api-key: your Anthropic API key (store in Make.com secrets)
   • anthropic-version: 2023-06-01
   • content-type: application/json
4. Body type: Raw / JSON
5. Body: Your JSON payload with model, max_tokens, system, and messages

To replicate a "Project," add a Data Store module before your HTTP call that retrieves your stored system prompt and any relevant document snippets, then map those values into the HTTP body using Make.com's variable syntax.

Handling Multi-Turn Conversations

If your workflow requires back-and-forth with Claude (rather than single-shot calls), here's a clean pattern for Make.com:

1. Start with a Data Store lookup to retrieve the existing conversation array for this session/user
2. Append the new user message to the array
3. Send the full array as the messages parameter in your API call
4. Parse Claude's response and append the assistant turn to the array
5. Save the updated array back to the Data Store
6. Use a router to check if the conversation is "done" or needs another turn

In production, I cap conversation threads at 15–20 turns before summarizing and starting a compressed context. Beyond that, you're paying for tokens that have diminishing returns on output quality — and in Claude's context window, older messages get less weight anyway.

When You Actually Need Claude Projects vs. API

This is worth being honest about. The API approach gives you more control, but it's not always the right tool. Here's a clear-eyed breakdown:

Real Workflow Examples for Marketers & Advertisers

Let me make this concrete with the kinds of workflows I actually build. These use the "Project replication" pattern described above.

Google Ads Performance Alerts

A scheduled Make.com scenario runs every morning at 7am. It pulls the previous day's campaign data from the Google Ads API, injects a system prompt stored in a Data Store (the same instructions I'd put in a Claude Project), and asks Claude to identify any campaigns with ROAS below 1.5x or CPA above target thresholds. Claude's analysis gets posted to a Slack channel. No one has to open a dashboard — the insight comes to them.

Ad Copy Generation at Scale

When a new product is added to an ecommerce client's Shopify store, a webhook triggers a Make.com workflow. The workflow fetches the product description, injects the brand's tone-of-voice guide (stored in Google Drive, pulled fresh each run) as part of the system prompt context, and asks Claude to generate 5 RSA headline variants and 3 description variants. The output gets written directly to a Google Sheet for human review before upload. The brand guide is the "Project knowledge" — it's just living in Drive instead of the Claude UI.

Monthly Reporting Narrative

At month-end, an n8n workflow aggregates performance data across channels, structures it as a JSON payload, and sends it to Claude with a system prompt that instructs it to write a plain-English executive summary using the client's specific reporting template (injected as context). The output goes into a Google Doc. What used to take 90 minutes takes <3 minutes of human time (just QA and send).

What's Coming: Will Anthropic Expose Projects via API?

As practitioners in this space often discuss, the gap between Claude's UI features and its API surface area is a known friction point. Anthropic has been expanding the API steadily — files API, extended context, tool use improvements — and it's reasonable to expect that some form of Project management endpoint will arrive eventually.

When it does, it will likely let you create, update, and reference Projects programmatically, probably giving you a project_id you can pass with API calls. Until then, the DIY approach I've outlined here is both more flexible and more production-ready than waiting for a managed endpoint. You own your storage, your prompts, and your conversation history — which means you can debug, audit, and modify your agent's behavior without depending on Anthropic's UI decisions.

Keep an eye on the Anthropic API changelog — new capabilities tend to ship with meaningful notices there before they show up in community discussions.

What to Do Next

If you're trying to use Claude Projects inside Make.com or any automation tool, here's your concrete action plan:

1. Extract your Project instructions. Go into your existing Claude Project, copy the system prompt verbatim, and paste it into a Make.com Data Store record, a Google Sheet cell, or a Notion database property. This is your "Project config" going forward.
2. Set up the HTTP module. Use Make.com's HTTP module pointed at https://api.anthropic.com/v1/messages with your API key in headers. Test with a hardcoded system prompt first to confirm the connection works before adding dynamic retrieval.
3. Map your document context. List every file you've uploaded to your Claude Project. Decide where each lives in your automation stack (Drive, Airtable, a Data Store). Build a retrieval step that fetches relevant content before each Claude API call.
4. Add conversation memory only if you need it. Most automation workflows are single-shot (one input → one Claude response → output to another tool). Only add the conversation array management pattern if your use case genuinely requires multi-turn dialogue in an automated context.
5. Version your system prompts from day one. Before you run this in production, set up a simple log (even a Google Sheet) tracking your prompt versions. You'll thank yourself the first time an update breaks something that was working.

The bottom line: Claude Projects are a great UI experience, but they're not a capability ceiling. The API gives you everything Projects give you — and then some. Once you shift your mental model from "calling a Project" to "providing project-level context on each API call," Make.com and every other automation tool becomes a perfectly capable Claude orchestration layer.

Related Reading