Postman / Insomnia
Import the ready-made Postman collection, or the OpenAPI document, to explore every endpoint with a personal access token and test a webhook receiver against signed deliveries.
Subscriby publishes a Postman collection beside the OpenAPI document. It is generated from that document on every deploy, so it can never describe an endpoint the API does not have, and it carries what a plain OpenAPI import leaves out: worked request bodies, one saved response per documented status with the real error codes, a fresh Idempotency-Key on every write, ids that chain from a create to the reads that follow, and a simulated delivery of every webhook event, signed the way Subscriby signs.
Where it lives
| URL | Purpose |
|---|---|
https://api.subscriby.net/postman.json | The collection, in Postman's Collection Format v2.1. |
https://api.subscriby.net/postman-environment.json | The companion environment: baseUrl, and token and webhookSecret as secrets. |
Postman
- Open Postman → Import → paste
https://api.subscriby.net/postman.json, then importhttps://api.subscriby.net/postman-environment.jsonthe same way. - Select the Subscriby REST API environment and paste your
sbt_…token into itstokenvariable. The token lives in the environment, never in the collection, so the collection can be shared. Mint one on the dashboard under Settings → API Tokens; see Authentication. - Send Projects → List projects. Every request inherits
Authorization: Bearer {{token}}from the collection. - Create something, say Projects → Create a project. The test script captures the new record's id into
projectId, and the requests below it send that id from the same variable, so a folder runs top to bottom without pasting ids. Paste an existing id into a variable to work on a record you already have. - Optional query parameters are present and unticked; tick the ones you want.
What each request carries
- A worked body. Request bodies are filled with values the API accepts, in the shape the field descriptions prescribe: a
kindwith the one block that kind allows, ids as UUIDs, prices as decimals, times asHH:MM. - Saved responses. Open the examples dropdown on a request to see one response per documented status: the success shape, and each failure as the error envelope with the code the API answers that status with, its message and its remediation.
- A fresh idempotency key. Every
POST,PUT,PATCHandDELETEsendsIdempotency-Key: {{$guid}}, a new UUID on each send. Pin the header to a fixed value to replay the original2xxinstead of repeating the write; see Idempotency. - Tests. Each request asserts that the status is one the reference documents and that a success carries the
dataenvelope, so the collection doubles as a smoke test for the Collection Runner or Newman. - The contract facts. A request's description ends with the abilities the token needs, the webhook events the call fires and the MCP tools that wrap it, read from the document's
x-required-scopes,x-webhook-eventsandx-mcp-tools.
Testing a webhook receiver
The Webhooks · simulated deliveries folder holds one request per event, grouped by family, each posting the event's documented payload to {{webhookReceiverUrl}} with the SB-Event-Id, SB-Event-Name, Content-Type and User-Agent headers a real delivery carries. A pre-request script computes SB-Signature on each send from {{webhookSecret}}, exactly as the API does (t=<unix seconds>,v1=<HMAC-SHA256 of "<t>.<raw body>">), so your handler sees a delivery it cannot tell from a real one, signature check included.
- Set
webhookReceiverUrlin the environment to your endpoint under development (a tunnel such as ngrok works) andwebhookSecretto the secret you verify with. - Send Webhooks → Plan → plan.created. Your endpoint should answer
2xx; anything else is what a retry looks like in production.
See Signature verification for the check your handler performs.
Insomnia
Insomnia imports Postman collections as well as OpenAPI documents, so the same two files work there.
- Open Insomnia → Create → Import → URL → paste
https://api.subscriby.net/postman.json; the environment file imports the same way. - Set
tokenin the imported environment to your token. Requests inherit the bearer auth. - Prefer the raw OpenAPI document? Import
https://api.subscriby.net/openapi.jsonand choose Convert to Design Document to browse operations by tag. In that case add a Before-Request script that setsIdempotency-Key: {% uuid 'v4' %}, since the OpenAPI import carries no scripts.
Syncing updates
Both files are regenerated on every Subscriby deploy. Re-import to pick up new endpoints: the collection keeps a stable id, so Postman offers to replace the previous copy instead of adding a second one.
Using the spec for codegen
For code generation use the raw OpenAPI document, not the collection, as the input to:
openapi-generator(open-source, multi-language)- Speakeasy / Stainless / Fern (commercial, opinionated SDKs)
See the OpenAPI reference for the x-required-scopes extension — any of the codegen tools preserves it as a comment on each operation.
How is this guide?
Last updated on
Building Custom Agents
Build your own agent on the OpenAPI spec, a personal access token with narrow abilities, and outbound webhooks.
Subscriby Agentic Kit
A Claude Code plugin that teaches Claude to run a community, integrate the API and webhooks, and build a connector on Subscriby, with the MCP server bundled and every destructive tool guarded.