---
title: "Update Tenant Apify"
method: PATCH
path: "/api/v1/admin/tenants/{slug}/apify"
tags: ["admin"]
---

# Update Tenant Apify

`PATCH /api/v1/admin/tenants/{slug}/apify`

## Request

- Base URL: `https://yondry.app` (the document declares no server; this is the origin it was published from)
- URL: `https://yondry.app/api/v1/admin/tenants/{slug}/apify`
- Auth: none declared

Toggle the Apify Instagram-scraper extractor for a tenant and/or set its
per-day run cap. Per field: null (omitted) = leave unchanged.

This is the runtime replacement for what migrations 0035/0036
(`enable_apify_yondry_tenant` / `disable_apify_yondry_tenant`) did as
one-off data mutations — they exist only to flip `tenants.apify_enabled`
/`apify_daily_limit` for one hardcoded tenant row, which is config, not
schema; see docs/plan/2026-08-25-remediation-roadmap.md task 5.8 /
finding M9. Those two migrations are left as-is (already run in
production, never edit a landed migration) — this endpoint is the
intended path going forward. **Do not write another migration to flip a
tenant's Apify flags; use this endpoint instead.**

## Path parameters

- `slug` string, required

## Headers

- `X-Admin-Key` string, nullable

## Request body

- UpdateTenantApifyRequest
  - `apify_enabled` boolean, nullable
  - `apify_daily_limit` integer, nullable

## Response `200`

Successful Response

- TenantApifyResponse
  - `tenant_id` string, required
  - `slug` string, required
  - `apify_enabled` boolean, required
  - `apify_daily_limit` integer, required

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/yondry/apis/yondry-api.md) · [All operations](https://skmtc.dev/yondry/apis/yondry-api/llms.txt) · [OpenAPI document](https://skmtc.dev/yondry/apis/yondry-api/revisions/d2c213cea95b?raw)