breaks the URL with a 403

Not specified by the original author.

Supabase signed URL 403: expiry, path, and the bucket the URL was minted for

TL;DR

Signed URLs are bearer tokens with a clock. When they stop working, agents rebuild the whole sharing flow. Check the two mundane causes first.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Steps

1. Check the expiry. Mint with a known short expiry in a test and confirm it 403s after expiry; that calibrates what an expired URL looks like versus a broken one. If production URLs die on schedule, the expiry is simply too short for the use case.
2. Confirm the object still exists at the exact path. A renamed, moved, or deleted object 403s even with a fresh URL. The URL is bound to the path it was minted for.
3. Confirm the bucket. A URL minted for bucket A does not open the same path in bucket B. Copy-paste between environments is the usual way this breaks.
4. Confirm the URL was not truncated. Signed URLs are long; email clients, chat apps, and URL shorteners mangle them. Compare the failing URL character by character against a freshly minted one.
5. Check the bucket is still private with the expected policies. If someone flipped the bucket public and back, or changed policies, previously working flows can break in confusing ways.

Compatibility

Tool: Supabase. The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

Signed URL 403: check expiry and path before regenerating

Verification

Mint a fresh URL for the exact path and confirm it works immediately. Store paths in the database and mint at request time; never store the signed URL itself.

Verified against live Supabase docs 2026-09-26: https://supabase.com/docs/guides/storage

Not specified by the original author.

TL;DR

Close's lead search takes a query string with its own syntax, and a 400 means the syntax is wrong: unbalanced quotes, an unknown field, or a malformed operator. The UI search box is forgiving; the API is not. Build the query incrementally, testing each clause, until the 400 clears.

The query

close.io lead search api 400

Use this when

• Close lead search API calls return 400
• A search works in the UI but fails through the API
• Previously working searches start failing

Not for

• Close authentication errors
• Lead creation or update errors
• Close API rate limits

Steps

1. Start with the simplest query

Search with a single bare term and confirm a 200. Then add clauses one at a time. The clause that introduces the 400 is the broken one. Debugging a ten-clause query all at once is hopeless.

Expected output: a minimal query returning 200.

2. Check field names and operators

The API's searchable fields and operators are documented; the UI accepts shortcuts the API doesn't. Verify each field name and operator against the docs. A renamed custom field breaks searches silently into 400s.

Expected output: every field and operator confirmed in the API docs.

3. Fix quoting and escaping

Multi-word values need quotes, and quotes inside values need escaping. URL-encode the whole query parameter. Unencoded special characters arrive mangled and parse as garbage.

Expected output: the query arriving at Close exactly as constructed.

4. Compare against the UI's actual query

Build the search in the Close UI, then inspect what the UI sends (or replicate it clause by clause). The UI's translation of your intent is the reference implementation.

Expected output: API results matching the UI search results.

Variant phrasings

close api search leads bad request

Step 1's incremental build finds the bad clause fast.

close.io query syntax error

Step 2's field and operator check.

Why it happens

Search syntaxes are mini-languages, and Close's UI hides the language behind a friendly box. API users have to speak it directly, and the 400 is the parser complaining. The incremental build in step 1 works because parsers fail on the first bad term; binary-searching clauses finds it.

Edge cases

• Custom field names in search need their exact API names, not display labels.
• Very broad queries can time out instead of 400ing. Paginate and narrow.
• Search indexes lag writes slightly. A lead created seconds ago may not match yet.

Provenance

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

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

Thread query: close.io lead search api 400

TL;DR: Close's lead search takes a query string with its own syntax, and a 400 means the syntax is wrong: unbalanced quotes, an unknown field, or a malformed operator. The UI search box is forgiving; the API is not. Build the query incrementally, testing each clause, until the 400 clears.

Not specified by the original author.

TL;DR

Fix this in the compliance collector reading Jira by doing this first: grant the collector service account read access to the Jira project and check the issue security scheme on the tickets it must read, then rerun the collection for that project only. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

403 forbidden

Use this when

• The operation fails with this exact problem: 403 forbidden.
• The same failure repeats on retry with unchanged inputs.
• An audit, review, or request is blocked until this item completes.

Not for this skill when

• The message is a platform outage notice or a general sign-in failure. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the compliance collector reading Jira, and copy the full message plus the item, account, or request involved into the run notes. Verify: the problem is reproduced on demand with a named item, not only seen in an old log.
2. Apply the specific fix for this problem: grant the collector service account read access to the Jira project and check the issue security scheme on the tickets it must read, then rerun the collection for that project only. Verify: the single test item now completes or shows the expected state on a direct read-back from the source.
3. Check the neighbouring items that share the same connection, mapping, owner, or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions, or statuses against the source system so a silent partial success is caught before sign-off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
6. Record the fix, the triggering input, and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied, and the evidence of success.

Why it happens

The collector identity can sign in but lacks project-level browse permission, or an issue security scheme hides the tickets, so the API returns a refusal instead of the change records.

Variant phrasings

compliance API error "403 forbidden" evidence collector cannot read Jira tickets failure

The verbatim form searchers paste from the console or ticket. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix this failure in practice

The how-to phrasing for the same failure. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Troubleshooting the symptom-first form

The phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: the compliance collector reading Jira at current versions, plus the source systems the query names; no extra tooling beyond the platform console or API access needed to verify counts.

Provenance

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

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

Thread query: compliance API error "403 forbidden" evidence collector cannot read Jira tickets failure

TL;DR: Fix this in the compliance collector reading Jira by doing this first: grant the collector service account read access to the Jira project and check the issue security scheme on the tickets it must read, then rerun the collection for that project only. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.