How to automate Instagram posting with Claude Code (without browser automation)

A Claude Code Instagram automation workflow can publish without learning where to click in a browser. Claude Code can read source material, draft copy, check files, and call tools while a publishing connector handles authentication and delivery.

This guide builds that workflow with Groniz. Start with a real source, such as a product update or blog post. Claude Code turns it into a caption and image brief, then a person checks the facts, voice, and visual. After approval, the workflow uploads the media, creates a draft or scheduled post, and verifies delivery.

"Without browser automation" has a narrow meaning here. There is no UI scripting for the act of posting. You still need to connect the Instagram account through Groniz OAuth and the Console when the provider requires it. This replaces fragile click sequences with a tool-driven publishing path. It does not bypass account authorization.

What the workflow automates

Automate the handoff around the publish command as well as the command itself:

1. Read one authoritative source.
2. Extract claims, names, dates, links, and caveats.
3. Draft an Instagram caption and an image brief.
4. Stop for human approval.
5. Discover the live Instagram connector requirements.
6. Upload the approved media to Groniz.
7. Create a draft or scheduled post.
8. Verify the post record and, after publication, the delivery result.

Claude Code can trace a caption back to a source and prepare consistent files. The reviewer handles the judgment calls: a sentence may overstate the update, the tone may sound wrong for the brand, or the visual may imply something the product cannot do.

Choose how Claude Code will reach Groniz

Claude Code can reach Groniz through a Skill, the native CLI, or MCP. Anthropic describes Skills as reusable knowledge and workflows, while MCP connects Claude Code to external services and tools. You can use either route for a repeatable publishing procedure or combine them. The official Claude Code feature overview and Skills documentation explain the distinction.

For the Skill route:

npx skills add groniz/groniz-cli

For the native CLI route:

curl -fsSL https://groniz.com/install.sh | sh
groniz auth:login

For MCP, create an API key in the Groniz Console and add the remote HTTP server. Keep the options before the server name:

claude mcp add --transport http \
  --header "Authorization: Bearer YOUR_API_KEY" \
  groniz https://mcp.groniz.com/mcp

This follows Claude Code's documented syntax for connecting a remote HTTP MCP server. Treat API keys as secrets: do not paste them into prompts, source files, or version control.

The rest of this article uses CLI commands because they make each step visible. When Claude calls Groniz through MCP or follows the installed Skill, the sequence remains the same: authenticate, discover, upload, create, and verify.

Start with a source, not a blank prompt

Create a small working directory for each post. A simple layout is enough:

instagram-post/
  source.md
  caption.md
  image-brief.md
  review.md
  approved-image.png

Put the canonical input in source.md, or give Claude Code the URL of a product update or blog post it is allowed to read. The source should be the authority for factual claims. Brand guidance can shape voice, but it should not supply missing product facts.

Ask Claude Code for structured output instead of a loose instruction to "write an Instagram post." For example:

Read source.md and prepare an Instagram content package.

Write caption.md with:
- one caption grounded only in the source
- no invented results, customer quotes, dates, or capabilities
- a short checklist after a line containing exactly `Source-to-claim checklist:`

Write image-brief.md with:
- the single idea the image should communicate
- exact on-image copy, if any
- factual details that must remain accurate
- visual direction for a designer
- a list of claims or UI states the image must not imply

Do not publish anything. Stop after creating the two files.

The resulting files leave an audit trail. A reviewer can compare each claim with the source instead of trying to reconstruct what Claude may have inferred.

The image brief is not an instruction for Groniz to generate or resize media. Groniz receives the final approved file for upload. Image production remains a separate design or generation step, followed by review.

Put a real approval gate before publishing

Start with the facts. Confirm product names, feature status, dates, quoted language, and every implied capability against the source. Remove anything that depends on a guess.

Then read the caption aloud. Cut generic claims and excess setup, and check that the call to action matches the source. Posts do not need to sound identical, but the account should remain recognizable.

Finally, check that the image matches the brief, uses approved assets, and does not show an unavailable feature or fabricated interface. Record the approval in review.md, including the approved caption file and media filename.

A compact approval record might look like this:

Status: approved
Source checked: 2026-07-20
Caption: caption.md
Media: approved-image.png
Reviewer: initials
Notes: Feature wording matches the published update.

Claude Code should treat any status other than approved as a stop condition. This matters most when the source changes after drafting: approval for one revision should not silently carry over to the next.

Discover Instagram requirements at runtime

Do not hardcode an Instagram format into the automation. Instagram is one of the 32+ networks that Groniz supports, with standard Facebook-Business and standalone connection kinds. Provider capabilities still differ, including required settings, media support, and length rules.

Authenticate and inspect the live integration:

groniz whoami
groniz integrations:list
groniz integrations:settings [instagram-integration-id]

Treat groniz integrations:settings [id] as the live source of truth for that connected account. Read these fields before building the command:

• .output.settings.required for every mandatory provider setting
• .output.maxLength for the current content limit
• .output.tools for dynamic lookup methods exposed by that integration

If .output.tools contains a method needed to supply a required value, call it with the live method name and input schema:

groniz integrations:trigger [instagram-integration-id] [method] -d '{"key":"value"}'

If the tools array is empty, skip that step. Do not assume a tool exists.

Only continue with a single-image example if the live settings confirm that the connected provider accepts it. The same rule applies to any other format. This article deliberately does not prescribe a carousel size, aspect ratio, caption limit, or provider setting because the connected integration should answer those questions at runtime.

Upload the approved media first

Groniz expects uploaded media references, not a local path or arbitrary external URL in the post command. Upload the approved file and capture the returned .path:

MEDIA_PATH=$(groniz upload approved-image.png | jq -r '.path')

Check that the variable is non-empty before proceeding. Keep the uploaded path with the post record so a failed create command can be retried without losing track of the asset.

Now load the reviewed caption:

CAPTION=$(sed '/^Source-to-claim checklist:/,$d' caption.md)

That example assumes the checklist is appended under the exact heading shown. A safer production setup writes the publishable caption and review notes to separate files, then reads only the caption file.

Create a draft or schedule the post

Build the settings JSON from the live integrations:settings response. Supply every required value. Then create a draft:

groniz posts:create \
  -c "$CAPTION" \
  -m "$MEDIA_PATH" \
  -s "2030-01-15T16:00:00Z" \
  -t draft \
  --settings '[required-settings-json]' \
  -i "[instagram-integration-id]"

The timestamp is an ISO 8601 placeholder required by the create flow; replace it with the intended time before promotion. A draft is useful when a second person will review the assembled post in the Console.

Draft creation skips some content-length and provider-setting validation. A successful draft therefore does not prove that the post is ready to schedule. Re-run the live settings check, confirm the caption against .output.maxLength, and verify all required settings before promotion:

groniz posts:status [post-id] --status schedule

If the content and assets have already been approved and the schedule is final, create the scheduled post directly by using -t schedule with the intended timestamp. Scheduling is an external action, so the prompt to Claude Code should name the account, content files, media file, timezone or UTC time, and approval record explicitly.

Verify creation and delivery

Capture the post ID returned by posts:create. Then inspect the relevant window:

groniz posts:list \
  --startDate "2030-01-15T00:00:00Z" \
  --endDate "2030-01-16T00:00:00Z"

Verify the integration ID, status, scheduled time, caption, and media reference. After the scheduled time passes, check the record again for the delivery state and any returned platform URL or release ID. A command completing successfully only confirms that Groniz accepted the request; the later record is what confirms the publishing outcome.

When a delivery fails, keep the source, approved files, integration settings snapshot, post ID, and error together. That gives Claude Code enough evidence to diagnose the handoff without rewriting the content from scratch.

Turn the workflow into a repeatable Claude Code routine

After a successful manual run, encode the procedure as a project Skill or a clear repository instruction. The routine should require five inputs: source, account integration ID, approved caption, approved media, and publication time. It should stop if approval is missing, refresh the live integration settings on every run, upload media before creation, and return the resulting post ID for verification.

Keep content generation and publishing as separate invocations. A useful first command prepares caption.md and image-brief.md without side effects. A second command runs only after approval and handles discovery, upload, draft or schedule creation, and verification. Separation makes accidental publication less likely and makes each stage easier to inspect.

This system makes the workflow more consistent. It does not guarantee followers, reach, or engagement. Instagram's official creator guidance treats creation, engagement, reach, insights, and guidelines as separate parts of growth. Use the Instagram Best Practices hub and Instagram's guidance on growth when planning creative work. After publication, review native Instagram Insights and bring what you learn into the next source brief and caption review. The publishing automation should not invent a growth answer.

The result is a repeatable Claude Code routine that can prepare and publish an approved Instagram post without clicking through Instagram's interface.

Connect Instagram to Groniz Connectors and run the first workflow as a reviewed draft.