WeChat Official Account
qq.com · Storage · 1 record · JSON
WeChat Official Account — uploadimg (图文消息图片, the uncapped endpoint) Storage
fails: egressanonymousno cardRper-object-cap
| Free tier | NO documented count cap. The docs state explicitly: "该接口所上传的图片，不占用公众号的素材库中图片数量的100000个的限制" — images uploaded via this endpoint do NOT count against the 100,000-image library limit. Per-file cap 1 MB, JPG/PNG only. unit MB; metered on unstated |
|---|---|
| Price | none stated |
| Per-object cap | Per-file cap 1 MB (1000000 bytes) |
| Retention | | Images are permanent in practice (they must survive in published articles forever), but the service is tuned for article inline images, so bulk non-image binary upload is impossible and a hotlink-blocked 403 can appear without warning. |
| Egress | Free and unmetered — the response hands back a public CDN URL on mmbiz.qpic.cn ("url": "http://mmbiz.qpic.cn/XXXXX"), which is served by Tencent's CDN with no access_token and no auth header. This is the only genuinely anonymous read path found in this entire slot. |
| Identity | anonymous derived from the record's prose, not from an identity field, and no signup was executed: red to UPLOAD (2h expiry, refresh loop needed). Download is anonymous. mmbiz.qpic.cn applies a Referer/hotlink check — direct GETs without a WeChat/weixin Referer can be refused, which brea |
| Limits |
1 MB per image, jpg/png only. access_token required to UPLOAD (2h expiry, refresh loop needed). Download is anonymous. mmbiz.qpic.cn applies a Referer/hotlink check — direct GETs without a WeChat/weixin Referer can be refused, which breaks plain curl fetch fan-out and CDN-fronting. |
| Binding | per-object-cap the per-object cap sets the shard size and therefore the object count; it bounds the total more tightly than any headline quota |
| Interface | rest rest |
| Tooling | Trivial — one multipart POST: curl -F media=@test.jpg "https://api.weixin.qq.com/cgi-bin/media/uploadimg?access_token=ACCESS_TOKEN". No wrapper needed; any HTTP client plus a token-refresh loop (access_token lives 7200s) is the whole client. |
| Composes with | The absence of a count cap means one account is already unbounded in object count; the binding limit becomes 1 MB/file. 1 account = effectively millions of 1MB objects. Multiple Official Accounts (1 per entity) multiply further, but count is not the constraint — file size is. |
| Reliability | Images are permanent in practice (they must survive in published articles forever), but the service is tuned for article inline images, so bulk non-image binary upload is impossible and a hotlink-blocked 403 can appear without warning. |
| Notes | NO documented count cap. The docs state explicitly: "该接口所上传的图片，不占用公众号的素材库中图片数量的100000个的限制" — images uploaded via this endpoint do NOT count against the 100,000-image library limit. Per-file cap 1 MB, JPG/PNG only. |
| Evidence rung | reported One page read moves it to documented. |
| Checked | 2026-10-21 (inherited); stale on 2026-11-04 |
| Parsed numbers |
|
Evidence (2)
| date | source | what it proved |
|---|---|---|
| 2026-10-21 | developers.weixin.qq.com/doc/service/api/material/permanent/ | read live: '该接口所上传的图片，不占用公众号的素材库中图片数量的100000个的限制，图片仅支持jpg/png格式，大小必须在1MB以下' plus response field url = 'http://mmbiz.qpic.cn/XXXXX' |
| 2026-10-21 | mmbiz.qpic.cn/mmbiz_jpg/<synthetic-id> | probe: GET -> 400 text/plain (endpoint live and reachable anonymously; the 400 is a fabricated media id, not an auth wall) |
More fields (1)
{
"dead_end": {
"failure_class": "quota",
"why": "NO documented count cap. The docs state explicitly: \"该接口所上传的图片，不占用公众号的素材库中图片数量的100000个的限制\" — images uploaded via this endpoint do NOT count against the 100,000-image library limit. Per-file cap 1 MB, JPG/PNG only.",
"retry_when": null,
"first_recorded": "2026-10-21"
}
}Unknown or withheld values (4)
$.extras.dead_end.retry_whenprocess$.free_tier.notesprocess$.per_object_cap.notesnot-extracted$.retention.notesnot-extracted