Creators
Creator accounts as a connector may create them — the one call that turns a connector's sign-up form into an email-first account with a linked identity, and the two ways it is refused.
Subscriby\Connector\Core\Creators. A connector that declares creator_registration runs its own sign-up conversation on its shared installation and hands the completed form here with the account it was talking to. The core creates the email-first account, links that account as the creator's primary identity and sends the verification mail. The connector never sees the user beyond the ref.
register()
$creator = $creators->register(new CreatorRegistration(
name: $form->name,
email: $form->email,
password: $form->password,
identity: new IdentityRecord(
connector: 'example',
externalId: $account->id,
installationId: null,
displayName: $account->name,
username: $account->handle,
storageRef: (string) $row->id,
),
));Returns a CreatorRef (id, locale). Behind it the core runs the same registration action the web form runs: the address must be unused, the password meets the same rules, the account is created unverified with the verification mail on its way, and the vouching account is recorded and linked as the creator's primary identity on your connector.
RegistrationRefused
| Factory | When | What to tell the visitor |
|---|---|---|
emailTaken() | The address already has an account. | Sign in on the web, then link this account from Linked accounts. |
accountRefused() | The core would not adopt the vouching account: the connector has no shared installation to file it under, the account cannot be reached, or it already belongs to another creator. | Sign in on the web and link this account from Linked accounts; the exception's message carries the specific reason for your log. |
Both carry the reason; neither should be retried with a variation.
What stays with the connector
The conversation: asking for the name, the address and a password in the platform's idiom, showing the platform's own terms, validating as much as the platform allows before calling. Keep the answers in your own storage while the wizard runs and discard them once register() has answered; the password in particular is never written to a table of yours.
One call, no follow-up
There is no verify() or setPassword() here: verification is the mail's link, and the password is the one the visitor typed. The next thing the new creator does through your connector is create a project, through your ManagementSurface or the dashboard.
How is this guide?
Grants
The access ledger as a connector may read and write it — finding a grant by id or by the reference you issued, what a summary tells you, and when a connector records a grant itself.
Alerts
Where a creator's alerts go, as far as a connector may ask or change it — the one switch for the account in front of the connector, and what the core keeps to itself.