Skip to content

Document the SignalWire User Contact on brands and campaigns - #677

Open
glanotte wants to merge 6 commits into
mainfrom
glanotte/20360/signalwire-user-contact-docs
Open

glanotte wants to merge 6 commits into
mainfrom
glanotte/20360/signalwire-user-contact-docs

Conversation

@glanotte

Copy link
Copy Markdown
Member

References signalwire/cloud-product#20360 and signalwire/prime-rails#10090

What changed

signalwire_contact_emails is added to the campaign registry's brand and campaign resources: an optional list of email addresses that receives SignalWire's registration correspondence about that brand or campaign. It appears on both response objects, on brand create for managed and CSP brands, on campaign create for managed and partner campaigns, and on both update bodies.

Registration currently mails whichever admin of the Space happens to be the oldest, which is why the field exists. Left unset, a campaign falls back to its brand's addresses and then to the user who submitted the registration.

The brand's existing contact_email is untouched. That one describes the brand's own company and is what reaches TCR; the new field never does.

How it was verified

yarn build:specs regenerated fern/apis/signalwire-rest/openapi.yaml, committed alongside the TypeSpec source. yarn format:specs left all six files unchanged. yarn fern-check passes the API definition; locally it also prints the unauthenticated "Missing redirects check skipped" error, which needs FERN_TOKEN and runs on CI.

Risk and rollback

Additive: one optional property on four request bodies and two response objects. No endpoint, path, required field or existing description changes. Reverting the commit removes it.

Notes for review

  • The implementation is in signalwire/prime-rails#10090, in review and not yet on staging or production. Merging this documents a field the API does not serve yet.
  • The property is a list because a customer may want several people notified. The API also accepts a single address in place of a list; the description does not say so. Open: whether that leniency belongs in the docs or should stay undocumented.
  • Brand and campaign carry deliberately different descriptions, because the fallback differs: a campaign falls back to its brand, a brand only to the submitting user.
  • CreateCspBrandRequest and CreatePartnerCampaignRequest get the field as well. Those resources are registered directly with TCR by the customer, but SignalWire still raises the registration ticket, so the contact still applies.

Registration correspondence for a brand or campaign went to whichever admin
of the Space happened to be oldest. Both resources now take a list of
addresses that receives it instead, readable and writable through the API.

The brand's existing contact_email is unchanged and still describes the
brand's own company, which is what reaches TCR.

References signalwire/cloud-product#20360
@github-actions

github-actions Bot commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

@glanotte
glanotte marked this pull request as ready for review September 11, 2026 18:06
glanotte and others added 4 commits September 15, 2026 06:40
PUT /api/relay/rest/registry/beta/brands/{id} has been routed in
prime-rails (resources :brands, only: [:index, :show, :create, :update])
but the spec never declared it, so UpdateBrandRequest was an orphaned
model and the new signalwire_contact_emails field on it rendered nowhere.

Declares the operation, and widens UpdateBrandRequest to the fields the
Rails Update contract actually accepts. Documents the post-unverified
lock: only signalwire_contact_emails stays editable; anything else is
rejected with invalid_state.
The contract accepts name, status_callback_url and
signalwire_contact_emails; the spec was missing status_callback_url.
Adds it, carries the 3..64 length bound on name, and notes that omitting
signalwire_contact_emails keeps the list while an empty list clears it,
matching the brand update body.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants