To get error details from a specific Phantom launch, call GET /containers/fetch with the Container ID of the run and set withRuntimeEvents=true. Filter the response for entries where type is "error", or check exitCode - any value other than 0 means the run ended on an error.
When to use this
You might want to check a Phantom’s logs through the API when:
A launch failed and you want to identify the cause automatically.
You’re integrating PhantomBuster with tools like n8n, Zapier, or a custom monitoring script.
You want to programmatically flag or retry failed launches.
Before you start
Make sure you have:
- A valid API key.
→ See Create an API key. API keys can only be created by Workspace admins. - The Container ID of the specific launch you want to check.
→ See How to find your Container ID for API calls.
Step 1: Fetch the launch details
Call GET /containers/fetch from the PhantomBuster API reference.
Pass the following:
- Header: X-Phantombuster-key → your API key
- Query param: id → the Container ID of the launch you want to check
- Query param: withRuntimeEvents → true - returns the structured list of runtime events, including any errors. Required for error detection.
(note-lightbulb) Optional: also set withOutput to true to include the full raw console log of the run. This is useful when runtime events don't give you enough detail to diagnose the problem. It's more verbose and less structured — use it as a secondary option, not a default.
Step 2: Read the response
In the response, check two things:
- exitCode: if it's not 0, the run ended on an error.
- runtimeEvents: scan for entries where type is "error". This is the most reliable way to identify what went wrong.
Example of a failed run response:
{
"exitCode": 1,
"runtimeEvents": [
{
"type": "error",
"message": "..."
}
]
}
Step 3 (Optional): Filter or process the error data
If you're connecting the PhantomBuster API to an automation tool (like n8n, Zapier, or Make), add a Filter or IF node to detect failed launches automatically.
There is no failed status, and error slugs don't always contain the word "error" - filtering on either will miss real errors.
Use these reliable conditions instead:
- Any runtimeEvents entry has type = "error"
- exitCode is not 0
This allows you to take automated actions: send a notification, retry the Phantom, or log the error for review.
Frequently asked questions
What's the difference between /containers/fetch and /containers/fetch-result-object?
/containers/fetch returns metadata, status, and runtime events for a launch, including errors.
/containers/fetch-result-object returns the output data the Phantom produced.
Use /containers/fetch for error detection; use /containers/fetch-result-object when you need the actual results.
What does exitCode 0 mean?
The run completed without errors. Any other value (most commonly 1) means the run ended on an error.
Do error slugs always contain the word "error"?
No. Error slugs are internal identifiers and don't follow a predictable naming pattern, filtering by slug is unreliable. Use type = "error" in runtimeEvents or check exitCode instead.
What if runtimeEvents is missing from my response?
You need to pass withruntimeEvents=true in your request, it's off by default and won't appear unless explicitly enabled.
When should I use withOutput=true?
When runtimeEvents alone doesn't give you enough detail. withOutput returns the full raw console log - more verbose, less structured. Use it as a fallback.