Instagram DM automation: what Meta's API allows and doesn't

The first question anyone asks about a saves organizer is some version of: can it just read my saved folder? It is a reasonable thing to want. The folder already exists, it already has four hundred things in it, and reaching in to fetch them looks like the obvious job for a tool in this category.

The answer is no, and not because it is on a roadmap somewhere. The platform does not offer that door, and the specific set of doors it does offer ends up shaping everything about how these tools work — including the initially baffling fact that you sign up by sending a message, and that every reel has to be forwarded by hand.

There is no API for your saved folder

Your saves are private state on your own account. The Graph API — the interface an outside application actually talks to — publishes a defined list of endpoints, and reading the current account’s saved posts is not on it. There is no permission to request, no scope a reviewer could approve, no undocumented corner to be clever about. From outside, the folder is not so much locked as missing from the map.

That is worth stating bluntly, because the capability does get advertised. If a product claims to pull in the saves you already have, there are only two things it can be doing. One is asking for your Instagram username and password so it can sign in as you and drive the app — automation against the interface built for humans, which violates the platform’s terms and puts your credentials in a third party’s database. The other is describing something narrower and letting the phrase "import your saves" do work it has not earned. Neither is a technical achievement.

Sharing content outward is a completely different proposition. That is a first-class, documented, deliberately built action — the share sheet exists precisely so a post can be sent somewhere with the account holder’s intent attached, and a direct message to a bot is that path used exactly as designed. The asymmetry is not an oversight. Reading someone’s private state is dangerous by default and is therefore closed; sending something you picked is only as consequential as the thing you picked, so it is open.

What a DM integration actually requires

Using the supported path is not the same as it being easy. Before a bot can receive a single message, a specific stack of platform prerequisites has to be in place, and the list surprises people who assume a messaging bot is a weekend project:

• An Instagram Business or Creator account. A personal account cannot receive messages through the API at all. Converting is a settings change rather than a new account, but it is not optional and it changes how your profile behaves.
• A linked Facebook Page. In the Facebook-Login configuration most of these bots use, messaging permissions are granted against the Page rather than against the Instagram profile directly, so on that path an unlinked account cannot be authorised at all.
• A Meta Developer app with the Instagram Graph API product added. This is what issues the app ID and app secret that everything downstream authenticates with.
• Approved messaging permissions. In development an app works against your own test account; going beyond that means App Review, with a written justification per permission, screen recordings of the flow, and live privacy policy and terms URLs.
• A webhook endpoint reachable from the public internet over HTTPS. Meta pushes events to you — nothing polls, so there is no version of this that runs entirely on a laptop behind a router.
• Signature verification on every incoming payload, using a secret held by both sides. This is the load-bearing one, and it gets its own section below.

There is an operational tail as well. Access tokens are short-lived by default and the long-lived exchange lasts roughly sixty days, which means a working integration has a rotation chore attached to it forever. None of this is exotic, but it is the reason DM-based tools tend to be one bot serving many people rather than something you install for yourself in an afternoon.

Webhooks, and why signature checks are not optional

A webhook is a URL you hand to Meta so it can post to you when something happens — a message arrives, a comment lands. The design is efficient and the consequence is unavoidable: the URL has to be reachable from the open internet, which means it is reachable by everyone on the open internet. Your endpoint has no way of knowing, from the request alone, whether a given POST came from Meta or from a script that found the address.

What resolves that is a shared secret established when the app is created. Every genuine delivery carries a header — X-Hub-Signature-256 — holding an HMAC computed over the exact request body using that secret. The handler recomputes the same HMAC over the bytes it received and compares the two, using a constant-time comparison so the check itself leaks nothing. Equal means the sender held the secret. Unequal means the payload is discarded before anything reads it.

Leave that check out and the endpoint is no longer a webhook handler; it is a public write interface that accepts instructions and believes them. It will accept that a message arrived, that a particular account sent it, and that a particular reel should be filed into a particular library, because it has no independent source of truth about any of those things. There is nothing subtle about the failure and nothing sophisticated required to trigger it, which is why verification runs first, before parsing, and why an unset secret should stop a deployment rather than log a warning and continue.

Messaging windows

The second constraint is about timing rather than access. Platform messaging rules govern when an application is permitted to send a message to a person, and the broad shape is that replying within a bounded window after the person contacts you is allowed, while messaging someone who has not written to you is restricted to narrow, pre-approved cases.

The reasoning is not hard to reconstruct. A messaging API where any business could open a conversation at will would become a spam channel within a week, and the inbox would stop being worth opening. The effect on a tool like this is that its entire interaction model is reactive by construction. It answers; it does not initiate. Share a reel and it confirms. Send nothing and it says nothing, indefinitely. Anything that would require reaching out later — a weekly digest of what you saved, a nudge about reels that failed to process — is not a feature someone forgot to build. It is a message the platform would decline to deliver.

What this means for you as a user

All of that is developer-facing, but it resolves into a handful of properties you can actually rely on as the person using such a bot:

• You never hand over your Instagram password. The bot authenticates as itself against the API. It holds no session on your account and cannot act in your name.
• The bot only sees what you deliberately send it. It has no view of your feed, your saved folder, your conversations with anyone else, or what you watched last night. Its window onto your account is one message wide.
• Everything in the library got there because you sent it. Nothing arrives from something you merely watched, paused on, or lingered over, so the library ends up being a record of decisions rather than of behaviour — which is a meaningfully different thing to have stored about you.
• Your existing saves stay where they are. A backlog cannot be moved across in one operation; the only route in for something you saved last year is to open it and send it like anything else, one at a time, for the ones worth the trip.

The last one is a genuine cost and it deserves better than a shrug. An empty library answers no questions, and no amount of good design inside a product compensates for content it is not permitted to reach. The only honest mitigation is temporal: the backlog is fixed in size and the forward stream is not, so the gap closes on its own if you keep going. A month of ordinary scrolling puts more into a library than most people’s existing folder holds that they would ever actually retrieve.

One consequence sits underneath all of this and rarely makes it onto a feature list: anything built on someone else’s messaging API is a tenant. Permissions get renamed and deprecated, review criteria tighten, and access can be suspended or withdrawn without notice — the terms of every product in this shape say so, ours included, because saying otherwise would be a lie. That is not an argument against using such tools. It is an argument for preferring the ones that will tell you which platform rules they are standing on, since a product unwilling to describe what it is built on is in no position to tell you what happens to your library if that ground moves.