API reference · Media

Read uploaded-media retention policy

GET /v1/media/policy

Applies to PostLake uploads on every plan while the account remains open, not external URLs. Minimum dates are not expiry dates. Source URLs are public; cancelling a post does not delete media. This is publishing storage, not a backup service. See https://postlake.dev/terms#media-retention.

Request

Authenticate with a bearer API key. Agents calling over MCP authorise with OAuth instead and never handle the key.

curl -X GET https://api.postlake.dev/v1/media/policy \
  -H "Authorization: Bearer $POSTLAKE_API_KEY"

Response

Versioned minimum retention, scheduled protection and exceptions (200).

FieldTypeRequiredWhat it is
versionstringYes
minimumDaysintegerYes
scheduledProtectionstringYes
automaticExpirybooleanYes
exceptionsarray of stringYes
scopestringNo
accountRequirementstringNo
publicUrlsbooleanNo
postRemovalDeletesMediabooleanNo
backupServicebooleanNo

Example

{
  "version": "…",
  "minimumDays": 0,
  "scheduledProtection": "…",
  "automaticExpiry": false,
  "exceptions": [
    "…"
  ],
  "scope": "…",
  "accountRequirement": "…",
  "publicUrls": false
}

Limits

Reads are limited to 600 requests a minute per account. Every response carries X-RateLimit-Remaining and X-RateLimit-Reset, and a 429 includes Retry-After so a client can back off without guessing. Reads of network data (comments, followers, conversations) are metered in credits; reads of your own PostLake state are not.

Calling this from an agent

Agents do not call REST. They call tools. Over the hosted MCP server this operation is upload_media, and the agent authorises with OAuth so your API key is never pasted into a chat or seen by the model. The reply comes back in the same normalised shape you see above, which is what lets an agent reason about it without a per-network branch.

You control what any one agent may do with it: which brands it may act for, which networks it may reach, how much it may do in a day, and whether it may spend credits you bought up front. See the MCP server.

Errors

Every failure uses one shape: a stable type, a granular code, the field at fault in param, and a plain-language fix. An agent can act on it without a person reading the message. See Errors and retries.

Check the result before retrying a write. Only operations that explicitly support idempotency can safely replay an Idempotency-Key.

Common questions

Can an AI agent do this without the REST API?

Yes. Over MCP the same job is the upload_media tool. The agent authorises with OAuth, so no API key is pasted into a chat or seen by the model, and the answer comes back in the same normalised shape.

How often can I call this?

Reads are rate limited per account and every response carries X-RateLimit-Remaining and X-RateLimit-Reset. On a 429 the Retry-After header tells you how long to wait.

What happens when it fails?

You get one error shape: a stable type, a granular code you can branch on, the offending field in param, and a fix written so an agent can correct itself rather than stop. Full list on Errors and retries.

Related