Connect MaxAPI images to n8n without duplicate submissions
Configure a manual submit workflow and a separate status check with HTTP Request, credential storage and explicit task-state handling.
Technical review:
1. Store authorization as a credential
Create an HTTP Header Auth credential with Name Authorization and Value Bearer YOUR_MAXAPI_KEY, replacing only the placeholder inside the credential editor. Choose Generic Credential Type → Header Auth on the HTTP Request node and select that saved credential. Do not place the key in a URL, Code node, JSON body or screenshot. Confirm model permission, any pinned route and available balance in Console first. Restrict workflow access because execution records can contain prompts and private result URLs.
2. Submit once from a manual workflow
Create a workflow with Manual Trigger → HTTP Request. Use POST https://api.maxapi.dev/v1/images/generations, JSON body, and the payload below. Start with a single input item. Select JSON response format, keep Never Error off, disable redirects and leave SSL verification enabled. Leave automatic retries and pagination off for this POST. Execute only when you intend to generate one image, then save the returned id and poll_url in your own job record. Do not rerun this workflow merely to refresh a task’s status.
{
"model": "google/gemini-3.1-flash-lite-image",
"prompt": "A red ceramic bowl on a cream background, soft studio light.",
"resolution": "1K",
"aspect_ratio": "1:1",
"n": 1,
"async": true
}3. Check status in a separate GET-only workflow
Create a second workflow with its own Manual Trigger and one HTTP Request GET node, using the same credential. Set the URL from the saved poll_url only after confirming HTTPS, host api.maxapi.dev and an image task path such as /v1/images/generations/{id}. A relative path must resolve against that fixed API origin. Reject other hosts and redirects instead of forwarding the key. This workflow must contain no generation POST. Keeping it separate prevents a status check from executing an upstream submit node again.
4. Branch on task state, not just HTTP success
In the default body-only JSON output, read status from the response body. If you enabled Include Response Headers and Status, inspect body.status instead of assuming the old field path. queued or running means wait before another GET; succeeded means inspect data; failed means record the error and stop. An unfamiliar state should stop for inspection. A 202 submission and a 200 status response are not proof that an image is ready. Keep result downloads in a node with no MaxAPI credential when fetching a different asset host.
5. Add bounds before scheduling or batching
Before automating, store job ownership, the accepted task ID and a submission state durably. Bound GET attempts, elapsed waiting time and worker concurrency separately; reaching a local limit does not cancel a server task. A timeout after POST is an unknown outcome: inspect history before another submission. Review 401/403 permissions, 429 limits and terminal policy errors instead of replaying every failure. Keep automatic triggers disabled until this recovery path and a spending limit are tested. This guide does not claim that n8n or MaxAPI supplies an automatic deduplication guarantee.
Model-specific parameters
Public configuration snapshot; not live availability. Follow each model page for its parameters, supported routes and reference limits.
- Gemini 3.1 Flash Lite Image
google/gemini-3.1-flash-lite-image - Gemini 3.1 Flash Image Preview
google/gemini-3.1-flash-image-preview