Workflow & Automation · Integration
PhantomBuster
Add PhantomBuster to your product for your customers, and give your AI agents governed access to it.
PhantomBuster's v2 API is keyed by a header carrying the organisation API key, and the core objects are agents, known as Phantoms, and the containers produced each time one runs. Launching an agent does not return results: it returns a container id, and you then poll the container for its status and output, which is why a synchronous integration looks like it silently did nothing. Arguments are passed as a JSON string that overrides the saved configuration for that launch only, so the stored setup and the effective run parameters can differ. Result data is written to a result object in storage rather than embedded in the API response, and plans cap both concurrent execution slots and total execution time, so queued launches wait rather than fail. fastn holds each customer's PhantomBuster key, keeps launches scoped to their own organisation, and handles reconnection when a key is rotated.
In your product
Embedded for your customers. Per-tenant auth, no per-customer code, maintained by fastn.
Let a customer connect their own PhantomBuster organisation so runs consume their execution time, not yours
Trigger a saved Phantom with per-record arguments and write the container output back into your records
Show run history and container status in your own UI so customers can see why a job is queued
Alert a customer when a Phantom fails or exhausts its execution time budget
For your AI agents
Governed, audited access for the agents you build, through the MCP server.
Let an agent launch only a named allow-list of Phantoms and never edit their saved configuration
Have an agent poll a container and report the outcome once the run finishes
Audit per tenant which Phantoms an agent launched, with what arguments, and how much execution time was used
Example prompt
Launch the profile export Phantom for this list and tell me when the container finishes.
Set up PhantomBuster in 4 steps
- 01Enable the PhantomBuster connector from your fastn dashboard.
- 02Have each customer authorise their own PhantomBuster account, so calls run under their credentials rather than a shared key.
- 03Decide which processes, runs and queues your product needs, map those fields, then enable the actions and triggers you want.
- 04Call it from your product and expose it to your agents through the same governed connection.
Why teams use the PhantomBuster integration
What you get by embedding it with fastn instead of building it yourself.
- Ship a PhantomBuster integration without building it. Your customers connect their own PhantomBuster account inside your product and work their processes, runs and queues there, with no per-customer code on your side.
- Handle the part that actually costs time: runs are asynchronous and can fail long after they are accepted, so an outcome that never arrives must look different from one that succeeded. fastn owns the auth, token refresh, rate limits, pagination and breaking-change fixes, so a PhantomBuster update is not your on-call problem.
- One integration serves your product and your agents. The same governed PhantomBuster connection powers in-product features and gives AI agents scoped, audited access, so you start work in the automation platform your customers already run, and get the outcome back without wiring it twice.
Used by these teams
Compare with
Often used alongside
Tools the same teams tend to run next to PhantomBuster, across other categories.
PhantomBuster integration FAQ
How do I add a PhantomBuster integration to my product?
Enable the PhantomBuster connector in your fastn dashboard, then let each customer authenticate their own PhantomBuster account. fastn handles the OAuth flow, token storage and refresh per tenant, so there is no PhantomBuster client code in your app and no per-customer branch in your codebase. Setup is 4 steps.
Do my customers each connect their own PhantomBuster account?
Yes. Every connection is scoped to the individual customer, so each authorises their own PhantomBuster account and only ever sees their own processes, runs and queues. That per-tenant isolation is the point of an embedded integration: you support the long tail of customer setups without maintaining an integration per customer.
Can AI agents use this PhantomBuster integration?
Yes. The same connection is exposed to your agents through the fastn MCP gateway, with permissions scoped per tenant and every call audited. Let an agent launch only a named allow-list of Phantoms and never edit their saved configuration
Who maintains the PhantomBuster integration?
fastn does. When PhantomBuster changes an endpoint, deprecates a field or alters its auth, the fix lands in the connector rather than in your backlog, and your customers' connections keep working.
Can my product start a PhantomBuster run and read its outcome?
Yes. Your product can trigger a process in the customer's own PhantomBuster account, pass it input, and take the result back as an event rather than polling for it.
What happens when a PhantomBuster run is slow or fails?
The failure surfaces with its error rather than as a silent timeout, and the run keeps its own identifier so a retry can be matched to the original. That matters more here than in most integrations, because a run that half-completed is not the same as one that never started.
What can I build with the PhantomBuster integration?
A common starting point: let a customer connect their own PhantomBuster organisation so runs consume their execution time, not yours. Teams also use it for the other use cases listed above, and expose it to agents for governed reads and writes.
How much does the PhantomBuster integration cost?
It is included. Pricing is based on connected accounts, not on how many connectors you enable, so adding PhantomBuster does not change your per-connector cost. You can start free with 3 connected accounts.
Add PhantomBuster to your product
Start free with 3 connected accounts. No sales call required, and no per-customer integration code.