> **For coding agents and LLMs:** This is one page from the Social Fetch docs (markdown export). For curated orientation and workflow guidance, start with [`/llms.txt`](https://www.socialfetch.dev/llms.txt); for agent onboarding and crawl rules, use [`/agents.txt`](https://www.socialfetch.dev/agents.txt); for the full endpoint list with links to pages like this one, use [`/llms-endpoints.txt`](https://www.socialfetch.dev/llms-endpoints.txt); for one platform's parameters and curls, use [`/llms-{platform}.txt`](https://www.socialfetch.dev/llms-tiktok.txt); use [`/llms.json`](https://www.socialfetch.dev/llms.json) when you need structured JSON for tool registration.

## This page

- **On-site (HTML):** [https://www.socialfetch.dev/docs/monitors/billing](https://www.socialfetch.dev/docs/monitors/billing)
- **Markdown (.mdx) URL:** [https://www.socialfetch.dev/docs/monitors/billing.mdx](https://www.socialfetch.dev/docs/monitors/billing.mdx)

## API base URL and authentication

- **API origin (from OpenAPI `servers`):** `https://api.socialfetch.dev`
- **Authentication:** send `x-api-key: sfk_...` on `/v1/**` routes unless the operation is explicitly anonymous (check OpenAPI `security`, the [API reference hub](https://www.socialfetch.dev/docs/api.mdx), [`/llms.txt`](https://www.socialfetch.dev/llms.txt), or [`/llms.json`](https://www.socialfetch.dev/llms.json) for each route).
- **OpenAPI JSON:** [https://www.socialfetch.dev/openapi.json](https://www.socialfetch.dev/openapi.json)

## Recommended docs entrypoints (this site)

- [Documentation overview](https://www.socialfetch.dev/docs.mdx) — top-level orientation (markdown).
- [Quickstart](https://www.socialfetch.dev/docs/quickstart.mdx) — authenticate with `x-api-key`, validate auth with `whoami`, and understand the JSON envelope.
- [SDK](https://www.socialfetch.dev/docs/sdk.mdx) — official TypeScript SDK guide, including `SocialFetchClient`, `Result`, and `unwrap()`.
- [SDK reference](https://www.socialfetch.dev/docs/sdk-reference.mdx) — exhaustive SDK method inventory and route mapping for agents, tooling, and power users.
- [Choose the right endpoint](https://www.socialfetch.dev/docs/choose-endpoint.mdx) — task-oriented route selection for smoke tests, profiles, list endpoints, and single-item lookups.
- [Capability matrix](https://www.socialfetch.dev/docs/capability-matrix.mdx) — fast comparison of identifiers, pagination, outcomes, media download, and SDK coverage.
- [Recipes](https://www.socialfetch.dev/docs/recipes.mdx) — copyable workflows (brand monitoring, transcripts, Ad Library, creator scoring, Reddit research) with credit callouts and SDK examples.
- [Integrations](https://www.socialfetch.dev/docs/integrations.mdx) — MCP for AI clients, n8n verified node, Apify Store Actors, SDK, and REST API connection paths.
- [MCP product page](https://www.socialfetch.dev/mcp) — hosted MCP overview, OAuth, Skills install.
- [MCP integration](https://www.socialfetch.dev/docs/integrations/mcp.mdx) — hosted `/mcp` server, OAuth, Cursor/VS Code/Claude install snippets, 162 endpoint tools, plus docs_search/docs_read for implementation help.
- [n8n integration](https://www.socialfetch.dev/docs/integrations/n8n.mdx) — install `n8n-nodes-socialfetch`, credentials, and workflow examples.
- [Apify integration](https://www.socialfetch.dev/docs/integrations/apify.mdx) — Store Actors under @social-fetch, PPE billing, dataset export, and quick start.
- [`/llms-endpoints.txt`](https://www.socialfetch.dev/llms-endpoints.txt) — every documented operation with a direct link to that route's agent-readable markdown page (prefer this over parsing OpenAPI).
- [`/llms-{platform}.txt`](https://www.socialfetch.dev/llms-tiktok.txt) — per-platform endpoint files generated from OpenAPI (parameters, credits, curls).
- [`/agents.txt`](https://www.socialfetch.dev/agents.txt) — agent crawl/onboarding file with capabilities, auth rules, and allowlist.
- [`/llms.json`](https://www.socialfetch.dev/llms.json) — structured machine-readable operation inventory with parameter names, pagination, outcomes, credits, and SDK mapping.
- [API reference hub](https://www.socialfetch.dev/docs/api.mdx) — human-friendly index of operations with links into generated pages.
- [Errors](https://www.socialfetch.dev/docs/errors.mdx) — shared error envelope and HTTP status guidance.
- [Credits](https://www.socialfetch.dev/docs/credits.mdx) — metering, `402`, and planning batch jobs.
- Outcome semantics such as `found`, `not_found`, and `private` are documented in [Errors](https://www.socialfetch.dev/docs/errors.mdx) and on operation pages when present in the OpenAPI contract.

## Markdown docs convention

- Every docs page has a markdown twin: append **`.mdx`** to the docs pathname (for example `/docs/quickstart` → `/docs/quickstart.mdx`).
- Agents that send `Accept: text/markdown` on `/docs/**` HTML URLs may receive markdown directly (same URL, `Vary: Accept`).

---
# Billing for monitors (https://www.socialfetch.dev/docs/monitors/billing)

Monitors bill like the rest of the API — no separate monitor fee.

## What's free vs. what bills

* **Management is free.** Creating, listing, getting, updating, deleting, pausing, and resuming monitors and webhook endpoints costs 0 credits.
* **Only the scheduled poll bills**, at that operation's **normal per-request price** — same as calling the route directly. A check against `GET /v1/twitter/profiles/{handle}/tweets` costs whatever that route normally costs.
* **Empty checks still bill.** A check that finds zero new items costs the same as one that finds ten. The upstream provider charges either way.
* **Triggers and test sends.** `POST /v1/monitors/{id}/trigger` is free; the poll it enqueues bills normally. `POST /v1/webhook-endpoints/{id}/test` sends a synthetic sample and never touches the source — 0 credits.
* **Shared targets.** If multiple customers monitor the same target, each is billed full price. Internally we coalesce the upstream fetch so we only pay the provider once.

## The cost math

```
perCheckCredits × checks per day = perDayCredits
perDayCredits × 30                = perMonthCredits
```

`perCheckCredits` is the operation's normal price. `checks per day` comes from the schedule: a 15-minute interval is `1440 / 15 = 96` checks/day; hourly is 24; 1-minute is 1,440.

| Interval | Checks/day | Example @ 1 credit/check | Example @ 2 credits/check |
| -------- | ---------- | ------------------------ | ------------------------- |
| 1 min    | 1,440      | 1,440/day · 43,200/mo    | 2,880/day · 86,400/mo     |
| 5 min    | 288        | 288/day · 8,640/mo       | 576/day · 17,280/mo       |
| 15 min   | 96         | 96/day · 2,880/mo        | 192/day · 5,760/mo        |
| 1 hour   | 24         | 24/day · 720/mo          | 48/day · 1,440/mo         |
| 6 hours  | 4          | 4/day · 120/mo           | 8/day · 240/mo            |
| 24 hours | 1          | 1/day · 30/mo            | 2/day · 60/mo             |

Check any operation's credit price on its [API reference](/docs/api) page before budgeting a schedule.

## Preview the cost before you commit

Every monitor create/get/list response includes a live `costPreview`. Add `?dryRun=true` to validate the request and return the preview without creating anything or running a baseline check:

```json
{
  "data": {
    "costPreview": {
      "perCheckCredits": 2,
      "perDayCredits": 192,
      "perMonthCredits": 5760
    }
  }
}
```

The dashboard create wizard calls this same endpoint as you move the interval slider.

## Optional spend caps

Set `spendCapCredits` on create (or `PATCH` later) to cap what one monitor can spend in a calendar month. Once it hits the cap, further checks are skipped for the rest of the month — same skip-and-record behavior as running out of balance, scoped to that monitor.

## Running low on credits

If the account doesn't have enough credits when a check comes due, the check is **skipped, not failed**. It's recorded in check history with a reason, and no charge happens. The monitor keeps trying on schedule. After **7 consecutive days** of skipped checks, status flips to `exhausted`. Top up and it resumes on the next scheduled tick — no manual re-enable.

## Plan limits

The only plan-gated limit is how many **active** monitors you can run. Poll frequency is not tiered — every eligible account can schedule down to the source's floor (currently 1 minute). Faster polling means more checks at the normal per-check price.

| Plan                   | Max active monitors |
| ---------------------- | ------------------- |
| PAYG (no subscription) | 5                   |
| Starter                | 25                  |
| Growth                 | 100                 |
| Scale                  | 250                 |

Limits are enforced at create, update, and resume. See [Pricing](/pricing) for current plan details.

## Where to go next

- [Credits](/docs/credits) — Metering, balance, and 402 handling across the API.

- [Monitoring quickstart](/docs/monitors/quickstart) — Create a monitor and see the dryRun preview in a real request.

- [Testing webhooks locally](/docs/monitors/testing-locally) — Test sends and manual triggers don't add a second charge.

- [Monitors API reference](/docs/api/v1/monitors/post) — Request/response schemas, including costPreview.