## TL;DR
After a migration, zero API usage usually means callers are pointed at a retired endpoint, holding revoked keys, or being rejected at the new gateway while their retries quietly gave up. Gateway logs on both the old and new endpoints show exactly who is calling what and what they get back.

```text
api usage fell to zero after migration: debugging broken integrations
```

## Use this when
- API calls read zero after an endpoint, cloud, or gateway migration
- Consumers have not confirmed they changed anything
- Old endpoint may still be receiving stray traffic

## Not for this skill when
- The API was intentionally sunset with a published end-of-life
- One consumer's own outage explains their silence

## Steps
1. Check the old endpoint and DNS target for traffic after the migration cutover. Verify: stragglers still calling the old endpoint are counted and identified by key
2. Check the new gateway logs for rejected calls: 401, 403, and 404 rates by consumer key. Verify: rejected consumers and their exact rejection reason are listed
3. Diff what consumers were sent (new base URL, new key format, new headers) against what the gateway now requires. Verify: the mismatch between instructions and gateway config is pinpointed
4. Fix the gateway rule or reissue the consumer config, then have one consumer run a live call. Verify: the call returns success and appears in the new usage report
5. Keep the old endpoint in read-only log mode for two weeks and alert on any key still using it. Verify: remaining stragglers are chased before the old endpoint is removed

## Variant phrasings
### API calls zero after migration
A related phrasing for the same underlying problem.
### integrations broken after endpoint move
A related phrasing for the same underlying problem.
### gateway rejecting migrated consumers
A related phrasing for the same underlying problem.

Compatibility: Compatibility: API gateways and management platforms (Kong, Apigee, AWS API Gateway) with key-based consumer reporting, current versions.

## Why it happens
Migrations fail at the seams: the new system works in tests while real consumers hold old URLs, old keys, and old assumptions. Both gateways keep logs, so the migration story is fully written down; the work is reading both sides instead of only the new one.

## Edge cases / pitfalls
- Consumers with aggressive retry backoff may take days to surface after a fix. Notify them directly rather than waiting for traffic.
- A zero can hide in reporting if the new gateway logs under a new product or environment name. Check the report filter before the gateway.
- Revoked old keys sometimes belong to dormant but contracted consumers. Contact owners before final decommission.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3-o4IuvCLHuOj1HJLguBOQ