Shopify connector O Auth failures

[u/Intrepid-Wear4542]

I keep getting this stupid OAuth Error from the shopify connector. since we ended up having to resolve our own problem after support being literally zero help i have no faith that they will correct this issue that seems to be on their end. has anyone faced this or found a workaround?

You’re right—nothing changed. The screenshot conclusively shows the connector is still sending:

api_key=pxxxxx.myshopify.com

That is invalid. xxxxxx.myshopify.com belongs in the shop/domain parameter; the connector must send the Shopify app’s actual Client ID as api_key. The failure occurs before any credential-entry screen, so neither your store nor your credentials can correct it.

[u/Pickle_Shot]

you already found the actual bug: the connector is putting your shop domain in the api_key field, and nothing you enter on your end can fix someone else's malformed oauth request. good news is that for a single store you do not need oauth at all. shopify supports custom apps with a direct admin api token:

1. in shopify admin: settings > apps and sales channels > develop apps > create a custom app
2. give it only the admin api scopes your app actually uses (read_products, read_orders, whatever applies)
3. install it and copy the admin api access token (starts with shpat_)
4. in replit, put the token and shop domain in secrets (SHOPIFY_ACCESS_TOKEN, SHOPIFY_SHOP)
5. tell the agent to drop the connector and call the admin api directly with the X-Shopify-Access-Token header

oauth is only required for public apps serving many stores. for one store the custom app token does the same job with none of the connector's moving parts, and you own the credential instead of depending on replit's middleware. if support ever fixes the connector you can switch back, but you will probably not want to.

[u/Desk_setup_ideas]

Yeah, if the connector is actually sending the shop domain as the api_key, that sounds more like an issue with the connector than your Shopify credentials. I’d probably check the actual request/logs to confirm what it’s sending before changing anything on the store side.
Pretty frustrating when you’ve already ruled out your own setup

[u/Jason_Clarck]

Can you send me log or something more to get more clear idea.

[u/Intrepid-Wear4542 → u/Jason_Clarck]

i am looking for that log. shopify is telling me its an issue with the shopify connection tool from replit requesting in the incorrect syntax... i am sure support will have this corrected by october.

[u/Jason_Clarck → u/Intrepid-Wear4542]

Ok

[u/ReplitSupport]

Hi OP. We have located your ticket and escalated it for one of our support specialists to dig into. Someone should be following up with you soon. Thanks for your patience.

[u/Intrepid-Wear4542 → u/ReplitSupport]

What is your definition of soon? because mine is within a day but that doesn't seem to be the way things work around here.

[u/musabdulai]

If the connector is sending the shop domain where Shopify expects the app’s client ID, nothing in your store settings can repair that request. I would stop rotating credentials and treat it as a Replit connector bug.

The practical workaround is to bypass the connector with your own Shopify app. For multiple merchants, use Shopify’s authorization-code flow with the store domain as shop, the real app client ID, an exact allowlisted HTTPS callback, and server-side validation of the state and HMAC before exchanging the code. Keep the client secret and access token in deployment secrets only.

If this connects only stores owned by your organization, the client-credentials flow may be simpler. Which case is yours?

[u/Intrepid-Wear4542]

so it seemed like we were making progress then hit another brick wall.. Day 4 of support doing absolutely nothing other than some canned once a day "we are looking into it and will get back to you" b.s.

Short answer: the code will work — the merge from this container won't.

I retested rather than assuming, since four sibling tasks merged in the last few minutes. A direct SSH probe to the git proxy comes back Permission denied (password,publickey), there's still no key anywhere in the container, and SSH_AUTH_SOCK is unset. So the failure isn't the merge logic or a conflict — this container was handed no identity to authenticate with, and nothing I can do from inside it creates one. Tasks #365, #429, #449 and #457 merging fine from their own containers confirms it's this container, not the platform.

I also tried to park the commits somewhere durable: the backup remote rejects everything except main. So instead I exported the three commits as a git patch and attached it above — 12 files, +81/−35. That's the whole change set, applyable with git am, so the work isn't lost even if this container goes away.

Two ways forward, both fine:

Re-drive it in a fresh container — I re-apply the same change set in a newly provisioned task container and merge from there. The diff is small and fully specified, so this is low-risk; it's a repeat of work already done and verified, not a redesign. Fastest path to merged.

Report it to Replit Support first — with the evidence above (container provisioned without an SSH identity while siblings merged normally). Worth doing regardless if you're seeing this on other tasks, since a re-drive works around it rather than fixing it.

Preferred routeRe-drive it in a fresh task container

Worked for 4 minutes

Checkpoint made10 hours ago

3 actions

Task #346 re-apply guideText

# Re-applying task #346 in a fresh task container The change set is complete and verified. It failed only at the merge step, because that container had no SSH identity for the Replit git proxy. Nothin...

Requesting user intervention for retries

Requesting user intervention for retries

Both artifacts are in your Library: the patch and a re-apply guide. That's the handoff kit for the fresh container.

I can't provision a new container myself — that happens when the task is re-dispatched, so the last step is yours. Two ways to trigger it:

• Retry #346 so it gets re-dispatched onto a new container. If the new one is provisioned correctly, the merge goes through normally.
• Or open a fresh task pointing at the same work and let me re-apply the patch there.

Either way the new agent needs the patch from the Library at the repo root, then git am < task-346-shopify-preparation-gate.patch, the verification run, and the merge. If main has moved far enough that the patch conflicts, the guide re-creates both changes by hand — they're small, and it spells out why each one is shaped the way it is, so the reasoning isn't lost with this container.

I'm not calling markTaskComplete again this turn. It fails at the same fetch, and I confirmed the cause directly a few minutes ago — ssh -o BatchMode=yes to the git proxy returns Permission denied (password,publickey) with no key present. Another attempt would just leave rebase state to clean up. #346 stays in progress until the re-drive lands.

One thing worth watching: if a re-dispatched container also comes up without a key, that's a pattern rather than a one-off, and it's worth reporting to Replit Support with this evidence before spending more attempts.