Projects
A creator's projects as a connector's creator surface lists, opens, creates, edits and deletes them — as the creator, under the dashboard's own tier limits and team permissions.
Subscriby\Connector\Core\Projects. A creator talking to a bot has projects the way they have them on the dashboard: the ones they own and the ones a team shares with them. Every call takes the CreatorRef of the account talking and runs as that creator, so the list is their sidebar's, a project they may not open is unknown here, and a create counts against the same project limit their plan sets. Every refusal reaches you as ProjectRefused with a stable reason.
listForCreator()
foreach ($this->projects->listForCreator($creator) as $project) {
// $project->id, ->name, ->handle, ->active, ->connector
}Every project the creator owns or shares through a team, in storage order, each as a ProjectSummary: the id, the name, the portal handle (null while the project has none), whether it is live, and the connector of its live installation (null while nothing is connected). The summary's ref() is the ProjectRef every other contract takes.
find()
$project = $this->projects->find($creator, $projectId); // null when it is not theirs to openA ProjectDetails: the summary's fields plus the description, the portal's address (built by the core from the handle), the branding switch, the terms and privacy links, and whether the project takes support messages. Null for a project the creator may not open, which is also what an unknown id answers, so a bot learns nothing the dashboard's 404 would not tell.
create(), update() and delete()
$draft = (new ProjectDraft)
->with(ProjectDraft::NAME, 'Weekend Club')
->with(ProjectDraft::DESCRIPTION, 'Saturdays only.');
$created = $this->projects->create($creator, $draft);
$renamed = $this->projects->update($creator, $created->ref(), (new ProjectDraft)->with(ProjectDraft::NAME, 'Weekend Club Deluxe'));
$this->projects->delete($creator, $renamed->ref());A ProjectDraft names fields one at a time: NAME, DESCRIPTION, HANDLE, TERMS_URL, PRIVACY_URL, ACTIVE and HIDE_BRANDING. A field the draft never names keeps its stored value, or the core's default on a create, so a conversation that changes one thing sends one thing; the name is the one field a create needs. The core validates what the dashboard validates (the name's length, a handle's shape and uniqueness, the tier a branding switch needs) and the delete is the dashboard's own, taking everything the project owns with it.
Refusals
ProjectRefused carries a stable reason: creator_unknown (the ref names no creator), project_unknown (no project the creator may manage has the id), invalid (a field the core refused; the message is the core's translated sentence), tier_required (the plan allows no more projects, or not this setting) and not_permitted (a teammate without the permission).
A connector's creator surface never re-implements a rule: the project limit, the team permissions and the handle rules are the core's, and a refusal names what the dashboard would have said.
How is this guide?
Last updated on
Storefront
What a project sells, as a connector's member surface offers it — the plans on offer by the core's own rule, the portal checkout that opens each, and the one purchase that completes on the connector, an access code.
Plans
A project's plans as a connector's creator surface lists, creates, edits, publishes and deletes them — subscription plans drafted field by field, with the options a draft picks from and the dashboard's own rules.