Table of Contents
TL;DR
If your flat file upload fails with 300403 and mentions a very long S3 URL containing X-Amz-Security-Token, you’re using a temporary (pre-signed) S3 link. These links expire, so when Amazon later tries to fetch the image, it gets HTTP 403 Access Denied. Use permanent, publicly accessible image URLs instead, or switch to Img.vision for permanent direct links and marketplace-ready delivery.
🔍 Symptoms you’ll see
In Seller Central processing report / error logs:
- Error code: 300403
- Message: “We can’t access your media … due to receiving 403 HTTP status code…”
Your media URL looks like:
https://<bucket>.s3.amazonaws.com/...?...&X-Amz-Security-Token=...&X-Amz-Expires=604799&X-Amz-Signature=...The link works in your browser right after you generate it, then fails later.
⏱️ Why this happens
Those long S3 URLs are pre-signed URLs. They include:
X-Amz-Security-Token(temporary credentials)X-Amz-Expires(how long the link remains valid)X-Amz-Signature(signature proving the URL is legit)
Pre-signed links are temporary by design. Your browser test might succeed now, but Amazon fetches images later when you upload your flat file. By then, the link can be expired or otherwise invalid, returning HTTP 403, which translates into error code 300403.
🕵️ Quick check: Is my URL a temporary S3 link?
If the URL contains any of these:
X-Amz-Security-Token=X-Amz-Expires=X-Amz-Signature=
…it’s a pre-signed (temporary) URL and not suitable for Amazon flat file image ingestion.
🪄 The right ways to fix it
Option A: Easiest & most robust: Use Img.vision (recommended)
If you just need reliable, permanent image links that marketplaces accept:
- Permanent direct links that don’t expire and preserve filenames.
- Dual-CDN delivery for speed and uptime (faster and more resilient than raw S3).
- Enterprise CDN firewall with marketplace-friendly optimizations (e.g., Amazon fetch patterns).
- User-friendly dashboard (bulk uploads, folders, copy links) instead of wrestling with the AWS console.
Result: Amazon marketplace can fetch your images anytime without tokens, cookies, or auth, no 403s from expired links.
Option B: If you must stay on S3: make the object public (with care)
Make specific product images public so they’re reachable without tokens.
- Check bucket guardrails
- In S3 Block Public Access settings, object-level public access must be allowed for this to work.
- Your org policy may forbid public objects, if so, you can consider Option A.
- Set the object ACL to public
- Open the object in S3 → Permissions → Access control list (ACL) → grant Public access (Read) to Everyone (or equivalent “Object can be public” toggle).
- Confirm the Object URL (without
X-Amz-*params) loads publicly in an incognito browser.
- Use the permanent object URL in your flat file.
- Example:
https://<bucket>.s3.amazonaws.com/path/to/image.jpgSecurity caution: Public objects are visible to the entire internet. Only set public access on assets intended for public distribution (e.g., product images). Never flip the entire bucket public.
🚫 What not to do
Don’t paste pre-signed S3 URLs from the AWS console (those “Share/Copy URL” buttons often produce temporary links).
Don’t rely on longer X-Amz-Expires as a “fix”. Even if you upload the flat file shortly after generating the pre-signed S3 URL, you can’t predict when Amazon will actually ingest the images; links can still expire at the wrong moment.
Don’t make the entire bucket public. You risk accidentally making private files public, which is a serious privacy and security issue. Such mistakes happen more often than you think even with big companies, you may have encountered a news article before about “company X leaking customer data” this way.
✅ Validate your fix (simple checklist)
- Open the exact URL from your flat file in an incognito window.
- Make sure it loads without being logged in to the AWS console and outside any company VPN.
- Use a quick header check:
- Open CMD on Windows or Terminal on macOS
- Type in
curl -I "https://your-domain-or-bucket/path/image.jpg" - You should see HTTP/1.1 200 OK (or HTTP/2 200). No redirects to auth pages.
- Retry your flat file upload.
❓ FAQ
Can I just increase X-Amz-Expires?
Not reliably. Even week-long pre-signed URLs can still expire before Amazon fetches them or get invalidated by automatic credentials reset. Use stable public URLs instead.
Is it safe to make images public?
For product images intended for public product pages, yes, that’s normal. Keep private assets private; don’t publicize your whole bucket.
Why does this only happen sometimes?
Because the timing of Amazon’s retrieval varies. Sometimes they fetch your image right after uploading your flat file, while your link is still valid; other times they fetch the image a bit later, at a time when the link has already expired, causing a 403.
💪 Why teams switch to Img.vision for marketplace images
- Zero-friction links: Permanent, CDN-backed URLs that never expire.
- Faster delivery: Dual-CDN setup that’s significantly faster and more resilient than raw S3 endpoints.
- Marketplace-ready: Enterprise CDN firewall with rules proven to work with Amazon and other marketplaces.
- Friendly Img Dashboard UI: Bulk uploads, folders and link management, no AWS console gymnastics.
- Predictable links: No token expirations, no credentials resets breaking flat file imports, no guesswork.
Bottom line: If your product images must always be fetchable by Amazon, use links that never expire.
