Building Your Plugin
This is the heart of the portal. A project holds one plugin; this page covers creating it, what every field means, and the path from draft to live on the marketplace.
Only an owner or admin of the project can create or edit the plugin.
Creating the plugin
From the project, choose + Create plugin. It opens a six-step wizard:
Basics → Integration → Webhooks → Listing → Pricing → Review
You can move back and forth. Each step validates before it lets you forward, and if the server rejects a field on submit, the wizard jumps back to the step that owns it rather than making you hunt.
Step 1 — Basics
| Field | Required | Notes |
|---|---|---|
| Name | ✅ | Your plugin's unique slug |
| Display name | ✅ | The human name on the listing |
| Description | — | What the plugin does |
| Category | ✅ | Which kind of plugin this is |
| Icon URL | — | Shown on your marketplace listing |
Lowercase letters, digits and hyphens only. acme-loyalty is valid;
Acme, acme_loyalty and acme loyalty are all rejected by the backend. Put
the pretty version in Display name.
The categories are the plugin types described in Plugin Types.
Step 2 — Integration
This step describes how SSP talks to you.
| Field | Required | Notes |
|---|---|---|
| Integration type | ✅ | REST API, OAuth 2.0, Webhook, GraphQL or SOAP |
| Auth type | ✅ | How SSP authenticates to your API |
| API endpoint | ✅ | Where SSP calls your plugin |
| Webhook endpoint | — | Where SSP delivers events |
| API key | ✅ | The credential SSP presents when calling you |
Auth type accepts exactly three values: api_key, oauth2 and jwt. It is
a dropdown rather than a text box for that reason — bearer, basic, none
and hmac are all rejected.
The API key here is yours, not SSP's: it is the credential SSP will present when it calls your endpoint. It is stored encrypted.
The sandbox's Webhook Tester delivers to the plugin's configured webhook endpoint, and it cannot change that setting itself. Leaving this blank means coming back here before you can test. See Testing in the sandbox.
Step 3 — Webhooks
Choose which events SSP should deliver to you. The full catalogue, with payloads, is in Webhooks; the Hello World tutorial builds a receiver that handles all of them.
Selecting nothing is allowed — the plugin simply receives no events.
Step 4 — Listing
| Field | Notes |
|---|---|
| Documentation URL | Your own docs, linked from the listing |
| Setup URL | Your hosted setup screen, if the plugin needs one |
| Visibility | Private or Public |
Public lists the plugin on the marketplace once it is approved and
published. Private keeps it to you. A Setup URL is how you host your own
configuration screen and receive the installation's pik_ key — that flow is
Setup Handoff.
Step 5 — Pricing
Free, or a subscription. Subscriptions are USD only, billed monthly or yearly, with an optional free trial in days. A subscription priced at $0 is rejected — make it free instead.
Step 6 — Review
A summary of name, category, integration, auth, API endpoint, visibility, how many events you selected, and pricing. Confirm to create.
Your webhook secret is shown once
The moment the plugin is created, the portal shows the webhook secret and will not show it again.
SSP signs every outbound webhook with this secret (X-SSP-Signature). It
cannot be retrieved later — only rotated, which invalidates the old one.
Store it in your plugin's environment now.
The plugin page
Once created, the plugin has its own page showing its metadata, endpoints, selected events grouped by domain, pricing, and — once it has been live — install, rating and review counts.
What you can edit, and when
Editing is gated by the plugin's status, mirroring the rule the server enforces, so the form only offers what will actually be accepted:
| Status | What you can edit |
|---|---|
| Draft | Everything |
| Changes requested | Everything |
| Submitted | Display name, description, documentation URL, icon URL |
| In review, Approved, Suspended, Rejected, Deprecated | Nothing |
Changes requested is a full-edit state by design: the reviewer sent it back for revision, so the edit-and-resubmit loop needs the same access as a draft.
Lifecycle states and the one action each offers
| State | Means | Your action |
|---|---|---|
| Draft | Yours to refine | Submit for review |
| In review | SSP is reviewing it | — wait |
| Changes requested | Reviewer wants edits; feedback is shown | Resubmit for review |
| Approved | Passed review, not yet listed | Publish to marketplace |
| Live | Published and installable | Unpublish |
| Rejected | Declined, with the reason shown | — cannot resubmit from the portal |
| Suspended | New installs paused; existing installs keep working | — contact SSP |
| Deprecated | Retired and unlisted; existing installs keep working | — |
Rejected, suspended and deprecated all keep the reviewer's or SSP's explanation on screen rather than leaving you guessing.
The wider review and marketplace process — what reviewers look for, changelogs, versioning — is Plugin Lifecycle.
Rotating the webhook secret
The plugin page can rotate the webhook secret. The new one is shown once, exactly like the original, and the old one stops working immediately.
Rotate when the secret may have been exposed, and deploy the new value to your receiver promptly — signatures made with the old secret will no longer verify.
Deleting
A plugin can be deleted from its page. This is not the same as unpublishing: unpublish takes a live plugin off the marketplace and is reversible; delete removes the plugin from the project.
Next
Test it in the sandbox before you submit.