Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →jeremylongshore/hubspot-auth
Authenticate production HubSpot integrations and survive the auth-side failures — 30-min token expiry storms, 500K daily rate-limit burnout, scope drift, token leakage in commits, multi-portal credential routing, OAuth refresh-token decay.
Passed 20 of 23 test cases with the skill, and 13 of 23 without it.
and 6 more in the full report
7 fixed13 passed either way3 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
I am writing a Node.js background process that calls HubSpot APIs concurrently across dozens of worker threads. To prevent thundering herd token refresh calls when access tokens expire, I plan to let requests fail with 401 and then trigger a refresh. How should I structure the token refresh mechanism to eliminate expiry storms?
| Checked | Without skill | With skill |
|---|---|---|
| Access tokens are refreshed proactively before expiration rather than reactively on 401 responses. | Missed | Passed |
| Concurrent refresh attempts share a single in-flight Promise gate so only one refresh HTTP call executes at a time. | Passed | Passed |
The instructions your model reads when the skill loads.
Authenticate a service to HubSpot and operate the auth layer in production. This is not a setup walkthrough — it is the auth code your integration runs at 3am when an OAuth token expires mid-batch, when a portal admin removes a scope, when an agency credential router sends a request to the wrong portal, and when on-call needs to rotate a leaked private-app token without dropping in-flight requests.
The six production failures this skill prevents:
403. Retrying does not help.pat-na1-* private-app tokens are wide-scope and not auto-expiring. A single leaked commit exposes the entire portal.HUBSPOT_ACCESS_TOKEN. Requests sent to the wrong portal silently operate on the wrong data.Build in this order. Each section neutralizes one production failure mode.
Reactive refresh on 401 is wrong. It doubles latency on the failing request and creates a thundering herd when all concurrent requests notice expiry at the same millisecond. Cache the token in-process and refresh proactively at 80% of TTL, behind a single-flight gate so concurrent callers serialize on one refresh.
This pattern applies to OAuth access tokens only — private-app tokens do not expire.
type Cached = { value: string; expiresAt: number };
let cached: Cached | null = null;
let inflight: Promise<string> | null = null;
export async function getToken(): Promise<string> {
// Refresh at 80% of TTL (1800s → refresh at 1440s elapsed, i.e. 360s before expiry)
test cases passed, vs 13 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.