> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://gtm-tools.sh/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://gtm-tools.sh/_mcp/server.

# Why did I get try_again_later?

> try_again_later is the transient signal from get_email and get_coordinates. It maps to HTTP 429 with Retry-After, it is charged, and each retry charges again.

Some tools can't answer *right now* for reasons that have nothing to do with your request: an upstream provider rate-limited us, a pooled session hit a cooldown, or a probe timed out. Rather than return a misleading empty result, those tools say so explicitly.

```json
{ "status": "try_again_later", "retry_after_seconds": 60 }
```

Over REST and MCP this arrives as **HTTP 429** with a matching `Retry-After` header, so well-behaved HTTP clients pick it up automatically.

## What it means

It's a statement about *us and our providers*, not about your arguments. The two tools that produce it today:

* **`get_email`**: the SMTP path was unavailable, or the pooled Google session is in cooldown. Internally these surface as `smtp_unavailable` and `google_cooldown`; both are already post-retry, since the verification legs retry inside their own budget before giving up.
* **`get_coordinates`**: the geocoder returned 429, or the request timed out.

Crucially, it is **not** the same as `not_found`. A `not_found` means the work happened and there's nothing to return, so retrying is pure waste. A `try_again_later` means the work didn't happen.

## What it costs

It costs the tool's full price, and **each retry costs again**.

The reason is the metering order: the cost is debited when the call passes the metering gate, which happens *before* the tool reaches its provider. There's no automatic refund. So a tight retry loop on a busy provider multiplies your spend without improving your odds.

| Outcome                          | Charged?                     |
| -------------------------------- | ---------------------------- |
| `429` / `try_again_later`        | Yes                          |
| `200` with `status: "not_found"` | Yes                          |
| `400`, `401`, `402`, `404`       | No, rejected before the gate |
| Session-required error           | No, gated ahead of metering  |

Full breakdown in [How Credits Work](/knowledge-base/getting-started/how-credits-work).

## How to retry

* **Honor `retry_after_seconds`.** It's a real number from the tool, not a constant: 60 for a provider rate-limit or Google cooldown, 30 for a network timeout.
* **Retry once, then move on.** If the second attempt also comes back transient, queue the input and come back later rather than looping.
* **Never retry in a tight loop.** Ten immediate retries cost ten calls and will almost always return the same signal.
* **Batch differently instead.** If you're sweeping a list and a few entries return transient, finish the list first and re-run only the stragglers.

```bash
# One retry, respecting the tool's own backoff
resp=$(curl -s -X POST "$API/get_email" -H "$AUTH" -d "$BODY")
if [ "$(echo "$resp" | jq -r .status)" = "try_again_later" ]; then
  sleep "$(echo "$resp" | jq -r '.retry_after_seconds // 60')"
  resp=$(curl -s -X POST "$API/get_email" -H "$AUTH" -d "$BODY")
fi
```

## When it means an outage

One `try_again_later` is normal background noise. A pattern is a signal:

* **Every call for one domain, repeatedly**: likely that provider's edge, not a general outage.
* **Every `get_email` call across many domains**: the SMTP verification path is degraded. Reads, LinkedIn tools, and signals will still work.
* **Every call to a session-backed tool**: check `list_connected_linkedin_accounts` (free). This is more often a stale pooled session than an outage; see [LinkedIn Session Expired](/knowledge-base/troubleshooting/linkedin-session).

If a whole tool stays transient for more than a few minutes, [contact support](/support) with the tool name and the exact arguments.