Hey,
I’ve submitted my Shopify app (Olvio, App ID 348203253761) to the App Store twice, and both rejections cite the same reason: the Anthropic API key I provided as test credentials is reported as invalid by the reviewer.
The problem: I’ve tested the exact same key in 100+ scenarios — fresh shops, multiple browsers, different sessions, after every code change — and it always validates. My validation flow does a real round-trip to Anthropic’s /v1/messages endpoint with a 10-token completion. It only returns “Invalid Anthropic key” when Anthropic itself returns HTTP 401/403. So if the reviewer sees “invalid”, Anthropic is actually rejecting the key on their end during the reviewer’s test specifically.
I’ve ruled out the obvious causes:
-
Key rotation between submission and review (key still active, never rotated)
-
IP allowlist on the Anthropic key (not enabled)
-
Geo restriction on my Anthropic workspace (Unrestricted, Global routing)
-
A bug specific to my deployment (same code path runs successfully for every other test I do)
My strongest hypothesis: when the reviewer copies the key from the Partners “test credentials” field, the paste pipeline is silently mangling it — invisible Unicode characters (U+200B zero-width spaces, U+FEFF BOM), curly quote substitution from auto-correct, or em-dash replacing the hyphen in sk-ant-.... From my side this looks identical to a real invalid key (Anthropic 401s on any of these).
I’ve now deployed defensive sanitization (strip zero-width chars, normalize em/en-dash to hyphen, remove smart quotes) plus a strict shape gate (^sk-ant-[A-Za-z0-9_-]+$) on the input — but I have no way to test whether this catches the actual reviewer scenario, since each review takes ~2 weeks and the rejection just says “didn’t work” without details.
What I’d appreciate:
-
If anyone from the App Store review team can do a one-shot controlled test where I provide the key via a direct channel (Pastebin, plain text email — anything that bypasses the Partners form), I can confirm within minutes whether this is a paste-pipeline issue.
-
If anyone has hit the same “third-party API key reported invalid by reviewer” pattern, how did you resolve it?
-
Confirmation on what the Partners “test credentials” field does to the text — raw paste, or does it apply any markdown rendering / autoformatting?
I’ve been bouncing between standard support (who say they can’t help) and reviewer feedback (which just says “didn’t work”) for a month. Any pointers from the community, or escalation contacts for the review team, would be a huge help.
Thanks,
Louis
Since posting, I ran a direct curl against Anthropic’s /v1/messages endpoint with the exact same key I provided as test credentials, from my development machine (so a regular consumer IP, no Cloudflare colos involved). The result:
POST https://api.anthropic.com/v1/messages
→ HTTP 200 OK
model: claude-haiku-4-5-20251001
response: “Pong” (valid completion, normal token usage)
This is a hard proof that:
- The key is active and not revoked
- There is no IP allowlist blocking the call
- There is no spend limit issue
- The model claude-haiku-4-5 (Olvio’s default) is accessible on the workspace tier
So when the reviewer sees “Invalid Anthropic key”, Anthropic is rejecting bytes that are not the bytes I provided. The only place that mutation can happen is in the paste pipeline between my submission and the reviewer’s input field.
I’ve been stuck in a “your key doesn’t work / yes it does, here’s proof / sorry can’t help” loop for a month. The curl above plus the diagnostic logs now in production should give us enough to close this conclusively. Any reviewer or staff member willing to coordinate — please DM me or comment here.
@Liam-Shopify i think you are the good guy for my problem
use cloudflare ai gateway and resubmit, had the same issue in a different context
Thanks again for the suggestion. To close the routing hypothesis cleanly, I ran additional tests through Cloudflare colos in different regions:
| Path |
Routing |
Result |
| Direct curl, Free fiber FR (IPv6) |
residential |
200 OK |
| Direct curl, Orange Mobile FR (IPv4) |
mobile carrier |
200 OK |
| Olvio Worker, CF colo France (CDG) |
embedded validation |
200 OK (hundreds of runs) |
| Browser VPN exit Singapore → Worker in CF Asia colo |
global |
200 OK |
| Browser VPN exit USA → Worker in CF US colo |
global |
200 OK |
5 distinct routing paths, 5/5 returning HTTP 200 with a valid completion. Anthropic accepts the key from anywhere, and the Cloudflare → Anthropic egress has no geo or colo restriction blocking it from any region I tested.
So AI Gateway wouldn’t shift the outcome on the routing axis — it would forward the same bytes to the same api.anthropic.com endpoint that already accepts them. The only variable left that differs between my testing and the reviewer’s session is the paste pipeline in the reviewer’s environment (browser, OS, clipboard manager, smart-quote autocorrect settings).
The byte-level hex logging I deployed in olvio-155 will capture the exact UTF-8 sequence of whatever arrives at my endpoint on the next review attempt — including any em-dash / curly-quote / BOM substitution that a stock paste pipeline might introduce silently. That’s what I’m waiting on.
Out of curiosity though, what was the context you ran into the same “API key invalid” pattern? Different LLM provider, different paste/transport scenario? Genuinely interested in the comparison.
have you tried submitting with cf ai gateway routing? if not, i suggest you do it. i ran into this exact same problem while working on internal tools for my company, so i cant share much specifics
i was scratching my head the same way, no need to overcomplicate it. im 99% sure this is the same issue, and even if by chance its not i’d say anything is worth trying in your case
Update — implemented AI Gateway routing for all Anthropic calls. Next review attempt will go through the gateway, with full request/response logging on the dashboard side for diagnosis.
Thanks for the push. Will report back once the next cycle completes.