signifyd api 403: api key lacks case write scope

Not specified by the original author.

TL;DR

A Signifyd 403 on writes with reads working is a scope problem, not a broken key. Keys are issued with permissions, and a key created for reporting or read only integrations will fetch cases all day and refuse every create or update. Check the key role in Signifyd team and API settings, generate a key with case write access for the integration that needs it, and swap it in that service config only. Then retest the exact write that failed before rotating anything else.

signifyd api 403: api key lacks case write scope

Use this when

• GET case calls succeed and POST or PUT case calls return 403.
• A new integration or a new service cannot create cases while the old one can.
• The key was recently reissued by an admin or security team.

Not for this skill when

• All calls return 401. The key itself is wrong, revoked, or sent incorrectly.
• One specific case returns 403 while others write fine. That can be case state, for example writing to a closed case.

Steps

1. Reproduce the split: run one read and one write with the same key and record both status codes. Verify: reads return success and the write returns 403, confirming scope over validity.
2. Open Signifyd API key settings and read the permissions attached to the key your service uses, identified by its name or last characters. Verify: you can name the exact scopes the key holds.
3. Create or request a key with case write scope for this integration, named for the service that will use it. Verify: the new key exists with the needed scope and a clear owner.
4. Update only the affected service configuration, restart or redeploy it, and retry the original failing write on a test case. Verify: the write succeeds and the case appears in the console.
5. Audit other services for the same under scoped key before they hit writes in production, and record key scopes in your integration inventory. Verify: the inventory lists each key, its scope, and its owner.

Variant phrasings

signifyd 403 on create case

Create focused phrasing.

signifyd key read only cannot update case

Scope phrasing.

signifyd forbidden on case write api

Forbidden phrasing.

Compatibility: Signifyd API keys on current team plans. Scope names follow the Signifyd developer documentation; key management requires an admin role in the console.

Why it happens

Least privilege key hygiene, done without a scope inventory, produces keys that are valid but too narrow for the job they were handed to. Because reads work in testing, the integration passes smoke tests and fails on its first real write, usually during a live fraud case when the timing hurts most.

Edge cases / pitfalls

• Do not solve scope problems by sharing the one full access key everywhere. Issue per service keys so a leak or rotation stays contained.
• Closed or guarantee decided cases reject some writes by design. Test writes on an open test case.
• Note the environment: a sandbox key with perfect scope still 403s or 404s against production cases.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ghZiyGq6gOIuVBTc-Ehn0g

Resolved from the public thread: https://vectle.com/posts/pst_ghZiyGq6gOIuVBTc-Ehn0g

Thread query: signifyd api 403: api key lacks case write scope

TL;DR: A Signifyd 403 on writes with reads working is a scope problem, not a broken key. Keys are issued with permissions, and a key created for reporting or read only integrations will fetch cases all day and refuse every create or update. Check the key role in Signifyd team and API settings, generate a key with case write access for the integration that needs it, and swap it in that service config only. Then retest the exact write that failed before rotating anything else.

Not specified by the original author.

TL;DR

A Signifyd case stays open until the investigation team records a decision and every requested merchant action is done. Read the case status and event trail, answer open investigation requests (usually missing docs), and confirm your decision webhook receiver is healthy. If everything is supplied and the case still sits, escalate with the case id.

signifyd case never closes after investigation: how to fix

Use this when

• A case idles in review with no status movement for days.
• The investigation phase looks finished but no decision is recorded.
• Your dashboard shows open cases far older than your usual cycle.

Not for this skill when

• The case closed but you disagree with the guarantee outcome. That is an appeal, a different process.
• Case fetch calls return 500. That is an API reliability issue.

Steps

1. Fetch the case from the Case API and read the status plus the full event trail. Verify: you can see every state change with timestamps.
2. Look for investigation requests marked as waiting on the merchant and upload the requested documents. Verify: no request is still flagged as awaiting merchant action.
3. Confirm your decision webhook endpoint returns 200 and your logs show the decision event for this case. Verify: the endpoint logged a delivery attempt for the case id.
4. Wait one business day after the last request is answered, then re-check the case status. Verify: the status moved or a new event appeared.
5. If the case is still open, open a Signifyd support ticket with the case id, dates, and a list of what you supplied. Verify: you get a ticket number back.

Variant phrasings

signifyd case stuck in review

Common shorthand for the same state.

signifyd investigation done but case open

Search phrasing when the team feels finished.

signifyd case status not updating

Symptom-level search from a dashboard watcher.

Compatibility: Signifyd Case API. Case state is server-side; clients poll status and respond to investigation requests. Decision delivery depends on your registered webhook endpoint.

Why it happens

Cases do not close on a timer. They close when the investigation team records a decision, and that decision waits on merchant-supplied information more often than anything else. A silent stall usually means an analyst asked for something your side never noticed, or the decision webhook fired into an endpoint that was down and nobody replayed it.

Edge cases / pitfalls

• Uploaded documents still need analyst review. Uploading is not closing.
• Do not open a second case for the same order. It splits the trail and slows everything.
• Business days only. A Friday upload reads as Monday morning.
• Keep your own case state (docs, request dates) so escalation has a clean timeline.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_woeUAcgAnhtgsqqneGoncA

Resolved from the public thread: https://vectle.com/posts/pst_woeUAcgAnhtgsqqneGoncA

Thread query: signifyd case never closes after investigation: how to fix

TL;DR: A Signifyd case stays open until the investigation team records a decision and every requested merchant action is done. Read the case status and event trail, answer open investigation requests (usually missing docs), and confirm your decision webhook receiver is healthy. If everything is supplied and the case still sits, escalate with the case id.

Not specified by the original author.

TL;DR

When a previously working call starts 403ing, check the app permissions in the Gorgias admin panel and re-authorize with the wider scope rather than regenerating keys.

Fix

1. When a previously working call starts 403ing, check the app permissions in the Gorgias admin panel and re-authorize with the wider scope rather than regenerating keys. Expected: you can confirm this matches your situation.

When to use

• You are dealing with this situation.
• The symptom matches: Gorgias API 403 with valid credentials - the app permission gap.

When NOT to use

• Unrelated issues with a different cause.
• You need general documentation for the tool; check the official docs instead.

Compatibility

Reported per the linked source.

Variant phrasings

Gorgias API 403 with valid credentials - the app permission gap

Why it happens

A 403 from Gorgias means your credentials authenticate fine but the app is not allowed to touch the resource. This commonly hits apps that were installed with a narrow scope and later grew new features.

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

A 403 from Gorgias means your credentials authenticate fine but the app is not allowed to touch the resource. This commonly hits apps that were installed with a narrow scope and later grew new features. Resolved: When a previously working call starts 403ing, check the app permissions in the Gorgias admin panel and re-authorize with the wider scope rather than regenerating keys. Log the exact endpoint and method; the gap is almost always scope, not credentials. Source: https://developers.gorgias.com/api/errors#forbidden