## TL;DR

Treat the refresh as a new org: update the agent's credentials and endpoints to the new sandbox, confirm API access is enabled for the integration user there, and smoke-test with a cheap read before restarting any queued jobs. Never resume the queue against the old org's endpoints.

```text
salesforce API_CURRENTLY_DISABLED on a sandbox the agent points at after a refresh
```

## Steps

1. Confirm the sandbox was refreshed: the old org Id and endpoints no longer resolve to the expected org. Expected: login against the new sandbox endpoints succeeds.

2. Update the agent's stored credentials, instance URL, and org Id to the refreshed sandbox's values. Expected: no config anywhere still references the pre-refresh org.

3. Verify API access is enabled on the refreshed sandbox and the integration user still has API permission. Expected: a limits or describe call returns 200.

4. Smoke-test with a single cheap read before restarting the job queue. Expected: the test read succeeds; only then do queued jobs resume.

## Use this when

- API calls fail with API_CURRENTLY_DISABLED after a sandbox refresh
- the agent's sandbox credentials stopped working overnight during a maintenance window
- jobs queue up against endpoints that no longer exist

## Not for this skill when

- a production org returning API errors - different cause, different handling
- expired passwords or locked integration users - those fail at login, not with this error
- rate limits or daily API caps - those return limit errors, not disabled errors

## Variant phrasings

### API disabled after sandbox refresh

Same root cause: the refresh created a new org the old config does not match.

### sandbox refresh broke the integration

Same fix: re-point credentials and re-verify API access.

### API_CURRENTLY_DISABLED on sandbox

Same fix: confirm the new org, update endpoints, smoke-test.

## Why it happens

A sandbox refresh does not update the sandbox in place - it replaces it with a fresh copy that has a new org Id, and tokens, endpoints, and sometimes API entitlements do not carry over. The agent keeps calling the old endpoints with the old session, and the platform answers that the API is disabled for that org context. From the agent's side it looks like a permission change; it is actually pointing at an org that no longer exists as it knew it.

## Edge cases

- Refreshes in progress: the sandbox may be unavailable for hours - check status before assuming config is wrong.
- Partial or developer sandboxes may have different license and API characteristics after refresh - re-verify, do not assume parity.
- Scheduled refreshes: put the agent's jobs on hold around the maintenance window instead of letting them fail.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_U-PVX5kPsEkWz8u0qp-dpg