Messenger error 100: Invalid attachment ID or not owned
Last verified against Meta for Developers - Messenger Platform error codes
Possible invalid ID or you do not own the attachment.What error 100 means
Code 100 with subcode 2018074 concerns reusable attachments: "Possible invalid ID or you do not own the attachment," with Meta's table pointing to the Attachment Upload API documentation. When you upload media once and receive an attachment_id, that ID is a reference into Meta's storage, and it is scoped: it belongs to the Page (and app context) that uploaded it. Sending with an ID that does not exist, was mistyped, or was minted by a different Page or app produces this error.
The scoping is what surprises multi-tenant platforms. A bot serving many Pages cannot upload a shared image once under Page A and reference it from Page B; each Page needs its own upload and its own ID. Migrations trip the same wire: move the Page to a new app, or rebuild the integration, and a warehouse of stored attachment IDs can silently become someone else's property from the API's point of view. IDs can also age out, Meta does not document a lifetime, but treating them as cache entries rather than permanent assets matches observed behavior.
Data-handling bugs supply the rest: IDs stored as numbers and mangled by precision loss, IDs confused with message IDs or asset URLs in the database schema, and copy-paste of example IDs from documentation. The correct mental model is: attachment_id is a per-Page cache key you must be able to regenerate, never the only copy of the asset.
What it looks like
{
"error": {
"message": "(#100) Possible invalid ID or you do not own the attachment.",
"type": "OAuthException",
"code": 100,
"error_subcode": 2018074,
"fbtrace_id": "BLBz/WZt8dN"
}
}Why it happens
- attachment_id minted by a different Page or app than the one sending.
- IDs corrupted in storage (numeric truncation, wrong column, whitespace).
- Aged-out or invalidated IDs replayed long after upload.
- Migrations that changed the Page/app pairing behind the integration.
- Placeholder or example IDs left in configuration.
How to fix Messenger error 100
- 1Confirm the sending Page is the one that uploaded the attachment; re-upload under the correct Page if not.
- 2Re-upload the asset via the Attachment Upload API with is_reusable=true and store the fresh ID.
- 3Store IDs as strings keyed by (page_id, asset); never share rows across Pages.
- 4On this error, fall back automatically: re-upload from the canonical asset URL, update the cache, resend.
- 5Audit stored IDs after any app or Page migration instead of waiting for send failures.
How to stop it recurring
Design attachment IDs as a regenerable cache: keep the canonical asset in your own storage, key cached IDs by Page, and implement the miss path (upload, store, send) once so every send site inherits it. That single pattern absorbs invalidation, migrations and multi-tenancy. The upload API's role among the media rules is shown in the Messenger limits reference, alongside the URL-fetch failure it helps you avoid.
Official reference: Meta for Developers - Messenger Platform error codes. See all Messenger error codes or the Messenger limits and quotas.
Related codes
- 100: Failed to fetch the file from the URLFailed to fetch the file from the url. Check that the URL is valid, with a…
- 100: Upload attachment failureUpload attachment failure. A common way to trigger this error is that the…
- 100: Attachment size exceeds allowable limitAttachment size exceeds allowable limit
Error 100 - quick answers
What does Messenger error 100 mean?
Code 100 with subcode 2018074 concerns reusable attachments: "Possible invalid ID or you do not own the attachment," with Meta's table pointing to the Attachment Upload API documentation. When you upload media once and receive an attachment_id , that ID is a reference into Meta's storage, and it is scoped: it belongs to the Page (and app context) that uploaded it.
How do I fix Messenger error 100?
1. Confirm the sending Page is the one that uploaded the attachment; re-upload under the correct Page if not. 2. Re-upload the asset via the Attachment Upload API with is_reusable=true and store the fresh ID. 3. Store IDs as strings keyed by (page_id, asset); never share rows across Pages. 4. On this error, fall back automatically: re-upload from the canonical asset URL, update the cache, resend. 5. Audit stored IDs after any app or Page migration instead of waiting for…
Stop debugging Messenger by hand
Connect the channel through Conferbot: tokens, webhooks and retries are handled, failures show as readable status.