n8n Gemini node adds Nano Banana 2.1: use it or call Sume?

Use n8n's Google Gemini node when you want Google's Nano Banana models on your own Google credential and are happy with one node doing the call. Use an HTTP Request node pointed at Sume when you want a durable job, a retry-safe Idempotency-Key, and a Sume-hosted result URL. The trigger for the question is n8n 2.43.3, which n8n's GitHub release entry dates 9 October 2026 and describes as showing Nano Banana 2.1 and 2 Lite in the Gemini node's image model list (read 2026-10-10).

Sume carries Nano Banana 2.1 as google/nano-banana-2.1. It does not list a 2 Lite id, so "2 Lite" in the n8n dropdown has no Sume equivalent today. The facts below come from the n8n release page and from Sume's Image API page.

What n8n 2.43.3 changed, and what it did not

The release entry lists two features. One is the Gemini node change above. The other blocks creating or updating workflows that contain deprecated nodes. The same page flagged the release as a pre-release when it was read, so check the version your instance actually runs before you plan around it.

The entry says nothing about how the node handles a slow generation, a retry after a timeout, or where the finished image lives. Those are the questions that decide cost in an automated workflow, so confirm them in the node's own documentation before you rely on the node for paid bulk work.

What Sume lists for the same family

Sume's image catalog is the source of truth, and it is a live endpoint: GET /v1/images/models returns every model id with its supported parameters, and GET /v1/images/models/{model_id}/endpoints returns the pricing lines for one model. Read those before you hard-code anything in a workflow, because the dropdown in a workflow tool and the catalog behind an API can drift apart.

The retired-id rule matters if you have older workflows. Sume's docs say Nano Banana 2 is retired, but google/nano-banana-2 and nano-banana-2 keep working and run as Nano Banana 2.1. The catalog no longer lists the retired id, so new workflows should name google/nano-banana-2.1 directly.

If a request sets a parameter that the chosen model does not list, Sume answers 400 unsupported_parameter rather than dropping it silently. That is useful in n8n, where a typo in a field name would otherwise produce a plausible but wrong image.

The HTTP Request node call

In n8n, add an HTTP Request node, set the method to POST and the URL to https://api.sume.com/v1/images, and send your key as a bearer header. Store the key in an n8n credential, not in the workflow JSON; the rules are on Sume's Authentication page. The curl below is the same request the node sends.

Treat the status code as the switch. 200 is the finished image response with data[].url. 202 is the job envelope, and you then poll GET /v1/jobs/{id}/status and fetch GET /v1/jobs/{id}/result, as described under Jobs and results. Slow settings such as 4K, high quality or a large n are the most likely to degrade to 202.

curl -X POST https://api.sume.com/v1/images \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: n8n-product-hero-0001" \
  -d '{"model":"google/nano-banana-2.1","prompt":"matte ceramic mug on a linen cloth, soft window light","aspect_ratio":"1:1"}'

Which one to pick

There is no single winner; the two calls solve different problems.

• Pick the Gemini node when you already hold a Google credential, want the 2 Lite option that Sume does not carry, and the workflow is a one-off or low volume.
• Pick Sume when the workflow can retry. A repeated POST with the same Idempotency-Key is the documented guard against billing a second image, and Sume's docs say not to retry unsafe submits without one.
• Pick Sume when the same workflow also makes video, audio or captions, so the key, the job envelope and the status polling are written once.
• Keep the model id in one workflow variable. When the catalog changes, you edit one value instead of hunting through nodes.

Check before you switch

Run GET /v1/images/models with your key and confirm google/nano-banana-2.1 is present for your workspace. Then call the endpoints route for that id and read the pricing line, because the billed amount comes back as usage.cost on each 200 response and is the number to log per run.

Finally, test a 202 path on purpose by requesting a slow configuration. A workflow that only handles 200 will work in the demo and fail on the first heavy image.