Phantombuster n8n integrationAutomate Phantombuster with n8n.
Your phantoms run on time, and nothing downstream ever hears about it. The Phantombuster n8n integration closes that gap with a single node: 5 operations on one resource, Agent, and no trigger of its own. Another starting point fires the workflow, n8n launches the agent and collects what it produced.
Verified Trustpilot reviews · AI, automation & growth agency
What does the Phantombuster n8n integration actually do?
The Phantombuster n8n integration wires the agents you already built in Phantombuster, the scripts people usually call phantoms, into a workflow that keeps running after they finish. The node speaks to the Phantombuster API and exposes 5 operations on a single resource, Agent: launch one, read one, list all of them, pull the output of the last run, or delete one.
First scenario, the scheduled harvest. A Schedule Trigger, the n8n node that starts a workflow at a fixed interval, fires in the morning, agent.launch queues your scraping agent, and a later run of agent.getOutput hands the results to Google Sheets as a fresh tab. Nobody opens the Phantombuster console to press a button.
Second scenario, enrichment that lands in the CRM. The output of an agent is a list of profiles, so the workflow filters it, drops the rows without an email address, and pushes what remains into HubSpot or Pipedrive. The same run can post a short recap in Slack so the sales team sees the batch arrive instead of asking about it.
Third scenario, the supervised launch. Max Instance Count lets a workflow launch an agent only when few instances are already running, which matters when several workflows share the same phantom. Pair it with agent.getAll to build a small inventory page of every agent in the organization, refreshed on a schedule.
Use the HTTP Request node when the operation you need is not among the 5 listed here. It calls any endpoint of the Phantombuster API and reuses the same credential through predefined authentication, so nothing extra to configure on the security side.
Two limits worth knowing before you start. Phantombuster has no trigger node in n8n, so a workflow never starts from a phantom finishing its run: you schedule the check, or you call an n8n Webhook, a URL a third party service can hit, from something else in your setup. And the node covers the Agent resource only, which means container management beyond reading the last output goes through HTTP Request. If you want the wider picture before committing, the n8n review covers what the platform does well and where it gets rough.
How do you connect Phantombuster to n8n?
- 01
Create the API key in Phantombuster
Open Workspace settings in your Phantombuster account, go to Third party API keys, and select Add API Key. The key belongs to the workspace, not to a person, so it reaches the agents of that workspace and nothing else. Copy it once, because that panel is where it lives and where you come back to revoke it if a workflow ever leaks it.
- 02
Store it as a credential in n8n
In n8n, open the Credentials menu and create a PhantomBuster credential. There is one field to fill, API Key, and one authentication method to choose from, API key. Save it and the credential becomes reusable: every Phantombuster node in every workflow picks it from a dropdown, and rotating the key later is a single edit rather than a tour of your workflows.
- 03
Select the credential and pick an agent
Drop the Phantombuster node in a workflow, choose the credential, then set the resource to Agent and pick the operation. Most operations show an Agent Name or ID dropdown that the node fills by calling your account. If the agent identifier comes from an earlier node instead, switch the field to an expression, the n8n syntax that reads a value from the incoming item, such as
{{ $json.agentId }}.
What can the Phantombuster node do?
The Phantombuster node exposes 5 operations across 1 resources. For each one: the node as you configure it in n8n, the required fields, and our field notes.
Agent
5 operationsDelete an agent
agent.deleteWhat you see in n8n
Notes & use cases
Removes an agent from the organization by its identifier. The deletion is final on the Phantombuster side, and the agent stops appearing in the lists the node loads for the other operations.
Key parameters
- Agent Name or ID: chosen from the dropdown the node fills with the agents of your organization, or written as an expression like
{{ $json.agentId }}when the identifier travels with the item.
Get an agent
agent.getWhat you see in n8n
Notes & use cases
Reads one agent and returns what Phantombuster knows about it, from its name to its current setup. Worth running before a launch when the workflow needs to check the agent still exists.
Key parameters
- Agent ID: a plain text field on this operation, not a dropdown, so the value is typed by hand or built with an expression such as
{{ $json.id }}from a previous node.
Get many agents
agent.getAllWhat you see in n8n
Notes & use cases
Lists the agents of the current user's organization. Each item comes back as its own entry, which makes the operation a natural first node when the rest of the workflow loops over agents.
Key parameters
- Return All: enabled, n8n goes through the pages of the API and brings back every agent of the organization.
- Limit: the cap that applies when Return All stays off, so the workflow only sees the first few agents.
Get the output of an agent
agent.getOutputWhat you see in n8n
Notes & use cases
Fetches what the most recent container of an agent produced. A container is one execution, so this is how a workflow reads the result of a run it queued earlier.
Key parameters
- Agent Name or ID: the agent whose last run you want to read.
- Resolve Data: off, the output arrives as a string; on, n8n resolves the data and the next node gets usable fields.
- Prev Container ID: retrieves the output from the container that follows the one you name, to avoid reading the same run twice.
Add an agent to the launch queue
agent.launchWhat you see in n8n
Notes & use cases
Queues an agent for execution. Phantombuster answers with the container identifier of the run it just created, which is the handle a later node uses to read the output.
Key parameters
- Agent Name or ID: the agent to queue, from the dropdown or an expression.
- Arguments and Arguments (JSON): the agent argument, field by field or as JSON, read in the script with buster.argument.
- Bonus Argument: a single-use value merged with the original argument for this launch only.
- Max Instance Count: launches the agent only if fewer instances than the number you set are already running.
Need help automating Phantombuster with n8n?
A person reads every message.
