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.

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.