Stria Partner API

Token-authenticated HTTP endpoints for listing clients and creating deliverables, plus HMAC-signed outbound webhooks. Included on every paid plan.

Version: 1.0

Status: Stable

Enterprise reference for Stria’s limited partner API: token-authenticated HTTP endpoints for listing clients and creating deliverables, plus HMAC-signed outbound webhooks.

Audience

Role	Use this documentation to
Integration engineers	Call endpoints from Zapier, Make, Figma plugins, or custom scripts
Security / compliance	Review authentication, storage of secrets, rate limits, and data minimization
Customer admins	Mint and revoke tokens, register webhooks, understand plan entitlements

Capability requirement

Inbound API access and outbound webhook registration require the api_access plan

capability, which is included on every paid tier:

Plan	Storefront	Plan id	Requests / minute
Freelancer Solo	Freelancer	`creator_solo`	60
Freelancer Studio	Freelancer	`creator_studio`	120
Freelancer Agency	Freelancer	`creator_agency`	300
Change Practitioner	Change	`change_practitioner`	120
Change Consultant	Change	`change_consultant`	300
Change Firm	Change	`change_firm`	300
Change Team	Change	`change_team`	300

Corrected 2026-08-20. This table previously listed api_access as available on Freelancer

Agency, Change Consultant and Change Team only. That was stale: migration 20261112000600

moved the capability down to the entry paid tier, on the reasoning that a one-person shop should

not have to buy a 15-seat agency plan to reach three endpoints that touch neither time nor money.

The differentiator moved from access to volume — hence the throughput column, and hence

rate-limits.md, which had the correct figures all along.

PLAN_CAPABILITY_MATRIX in src/lib/plans.ts is the source of truth here and is checked

against the migrations by npm run test:plan-caps.

Free and trial workspaces have no api_access: a tier that has not paid minting credentials is a

different decision with an abuse profile attached.

Slack incoming webhooks remain available to organization admins on all plans.

Without api_access:

Settings → Integrations blocks token and webhook creation
create_api_token / create_webhook_endpoint RPCs raise API access is a paid feature
Existing tokens receive 403 on API calls after a plan downgrade (revoke remains allowed)

Base URL

https://<PROJECT_REF>.supabase.co/functions/v1

Replace <PROJECT_REF> with your Supabase project reference. Both endpoints are deployed with JWT verification disabled at the gateway; authentication is the Stria API Bearer token.

Surface area (v1)

Method	Path	Description
`GET`	`/api-list-clients`	List active clients (id + display name)
`POST`	`/api-create-deliverable`	Create a deliverable and receive a share URL

Outbound webhooks are configured in the product UI (not via these HTTP endpoints). See webhooks.md.

Documentation map

Document	Contents
authentication.md	Tokens, hashing, rotation, least privilege
endpoints.md	Request/response schemas, examples
errors.md	Canonical HTTP status codes and bodies
rate-limits.md	Quotas and retry guidance
webhooks.md	Outbound events and HMAC verification
openapi.yaml	OpenAPI 3.1 machine-readable contract
changelog.md	Version history

Quick start

Upgrade to a plan that includes API & webhooks.
As an org admin, open Settings → Integrations.
Create an API token; copy the plaintext value (shown once).
List clients:

curl -sS \
  -H "Authorization: Bearer stria_<token>" \
  -H "apikey: <SUPABASE_ANON_KEY>" \
  "https://<PROJECT_REF>.supabase.co/functions/v1/api-list-clients"

Create a deliverable:

curl -sS -X POST \
  -H "Authorization: Bearer stria_<token>" \
  -H "apikey: <SUPABASE_ANON_KEY>" \
  -H "Content-Type: application/json" \
  -d '{"title":"Homepage mock","client_id":"<CLIENT_UUID>","embed_url":"https://example.com"}' \
  "https://<PROJECT_REF>.supabase.co/functions/v1/api-create-deliverable"

Supabase Edge Functions typically expect the project apikey (anon) header in addition to your Bearer token. The Stria API authorizes solely on the Authorization: Bearer stria_… token; the anon key is a gateway requirement, not an org credential.

Versioning policy

v1 is additive: new optional fields or endpoints may appear without a path bump.
Breaking changes (removed fields, changed auth, stricter required bodies) ship as a new major version and are announced in changelog.md.
OpenAPI info.version tracks the documentation contract version.

Security principles

Hashed at rest — plaintext tokens are never stored; only SHA-256 digests and a display prefix.
Org scoped — every request is bound to the token’s organization; cross-org IDs are rejected.
Entitlement enforced twice — at token mint (Postgres) and on every request (Edge Function).
Rate limited — fixed window per organization (see rate-limits.md).
Minimal data — api-list-clients returns only id and display name (no email or notes).
HTTPS only — webhook destinations and embed URLs must use https://.

Support

Product setup: Settings → Integrations in the Stria app
Operator runbooks: docs/verification.md, LAUNCH.md
Open an issue in the repository for contract bugs or documentation gaps

More reference

Authentication — How tokens are minted, stored, presented and revoked.
Endpoints — Every request and response shape, with worked examples.
Outbound webhooks — Signed HTTPS POSTs when work is signed off, a change order moves, or an invoice is paid — plus how to verify one and how to survive a duplicate.
Rate limits — Per organization, per minute, and published rather than discovered as a random failure.
Errors — What each status means, what the body carries, and which ones to retry.
Compatibility and versioning — What may change without notice, what may not, and how you are told.
API changelog — Every change, dated, including the ones that were corrections.

OpenAPI specification · API access is on every paid plan · Start your 14-day trial