Version

Activity API

Every mutation Subscriby performs, whether from the dashboard, the REST API, an MCP tool call, a Zapier step or a scheduled system task, is recorded against its subject in the activity log.

Every mutation Subscriby performs, whether from the dashboard, the REST API, an MCP tool call, a Zapier step or a scheduled system task, is recorded against its subject in the activity log. GET /v1/activity returns that log filtered to a single subject so agents and audit tools can reconstruct exactly what changed and who did it.

Endpoints

GET

The newest entries recorded against one subject, limit at a time (50 by default, 200 at most), newest first. Name the subject by alias and id:

curl "https://api.subscriby.net/v1/activity?subject_type=project&subject_id=$PROJECT_ID&limit=20" \  -H "Authorization: Bearer $SUBSCRIBY_TOKEN"

There is no paging beyond limit: the endpoint is a recent-history read, not an export. The subject is resolved through its own tenant-scoped query before activity is read, so passing the id of a project (or subscription, plan, member) that belongs to another team returns 404 RESOURCE_NOT_FOUND rather than an empty list; existence never leaks across tenants.

  • subject_type and causer_type use short morph aliases (project, project-subscription, project-subscription-plan, project-user, project-resource, user, …) rather than internal class names. Treat them as opaque strings. The subject_type query parameter accepts only the aliases listed on the endpoint; a class name is 422 VALIDATION_FAILED.
  • actor_kind distinguishes the surface the change came through: human (dashboard click), api_token (REST), mcp (MCP tool), zapier, webhook, system (scheduled job). Filter on it client-side when you need "everything the agent did yesterday" separately from dashboard clicks.
  • properties keys matching token, secret, password, api_key or api_secret (case-insensitive) are stripped at any depth before the response leaves the server, so LLM context windows never see credentials that were logged alongside a write.
GET
/v1/activity

Requires ability

The token must hold this ability, or the call is refused with 403.

Runs the same action from an agent, behind the same ability.

Authorization

bearerToken
AuthorizationBearer <token>

A personal access token minted on the dashboard under Settings, then Tokens, sent as Authorization: Bearer sbt_live_…. The token carries the abilities each endpoint lists under Requires ability and is frozen to one team.

In: header

Query Parameters

subject_type*ActivitySubjectType

The kind of subject, as a short alias: project, subscription (or project-subscription), member (or project-user), plan (or project-subscription-plan), access-code, coupon or project-resource. A class name is refused.

Value in

  • "project"
  • "subscription"
  • "project-subscription"
  • "member"
  • "project-user"
  • "plan"
  • "project-subscription-plan"
  • "access-code"
  • "coupon"
  • "project-resource"
subject_id*string

The subject's id.

Formatuuid
limit?integer

How many of the newest entries to return, 1 to 200; defaults to 50. A value above 200 is refused rather than clamped.

Range1 <= value <= 200

Responses

200OK

Array of ActivityResource

401Unauthorized

The request carries no bearer token, or one that is revoked, malformed, or minted for another environment (an sbt_test_ token on production).

403Forbidden

The token is valid but does not carry the ability this endpoint requires; error.context.required_ability names the one to grant. An endpoint that also checks who owns a row or which tier the account is on answers FORBIDDEN, TEAM_TIER_REQUIRED or CONNECTOR_TIER_REQUIRED with the same status, and says so in its own description.

404Not found

When the subject does not exist in the caller's tenant, or belongs to a project outside the token's scope:project: allow-list.

422Validation failed

The payload broke a rule, and error.fields maps each offending key to its messages. A refusal from the domain, such as a plan that cannot go on sale or a member who cannot be removed, uses the same code with error.message saying why and no fields. On this endpoint: VALIDATION_FAILED: when subject_type or subject_id is missing, the alias is unknown, the id is not a UUID, or limit is above 200.

429Too many requests

The token has spent its 300 requests a minute or 10,000 an hour; Retry-After says when the next one is accepted.

How is this guide?

Version

On this page

Subscriby is a product
designed by you — for you.
No boardroom full of executives deciding what we ships next. Our roadmap always shaped by you with your feedback.

Share feedback or a request