api-sdk-rb 1.11.111 → 1.11.133

data/spec/api/partners_api_spec.rb

@@ -32,7 +32,7 @@ describe 'PartnersApi' do
     end
   end
 
-  # unit tests for confirm_partner_adapter_connection_0
+  # unit tests for confirm_partner_adapter_connection
   # Confirm a partner's adapter address with the code that was emailed to it
   # Some credentials are an email address Widgetic sends a widget's messages to (`confirmation: email_code` in `getPartnerAdapterConnections`). Saving one with `setPartnerAdapterConnection` emails a six-digit code to it; this gives the code back. Only then is the address used: until it is confirmed, the widgets of the partner's customers that need it are not charged and their visitors are told the feature is unavailable.  The code works for 30 minutes and for five wrong tries. After that, save the address again and a new code is emailed (not sooner than a minute after the last one). A code that is not made of digits is refused without counting as a try.  Confirming an address that is already confirmed answers 200 with the same state, so a retry of a request that went through is harmless. Saving a different address, or the same one before it was confirmed, starts again.  This needs an API key with full access. The caller must be the person who administers the partner, or a Widgetic administrator. 
   # @param partner_id The partner that keeps the address
@@ -40,14 +40,14 @@ describe 'PartnersApi' do
   # @param credential_key The credential's name within the adapter
   # @param confirm_adapter_connection_request 
   # @param [Hash] opts the optional parameters
-  # @return [SetUserAdapterConnection200Response]
-  describe 'confirm_partner_adapter_connection_0 test' do
+  # @return [AdapterConnectionResponse]
+  describe 'confirm_partner_adapter_connection test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for create_partner_extra_credits_invoice_0
+  # unit tests for create_partner_extra_credits_invoice
   # Buy extra credits for a partner
   # Asks Widgetic for an invoice for extra credits, on top of the credits of the contract. Name the dollars; the invoice is for the most whole credits they buy at the **list price** of a credit (the price a contract may lower belongs to the contract), so it is never for more than you asked: 12.34 buys 123 credits and the invoice says 12.30. The smallest purchase is 10 dollars and one request buys at most 100000 (ask Widgetic for an invoice for more).  Pay the invoice with the link in the answer. When it is paid the credits are added **once, for good**, to the account of the person who administers the partner, which is the account everything the partner builds is charged to (`getPartnerCreditBalance` shows it). Extra credits **do not expire**, unlike the credits of a contract period, which end with it. Nothing is added before the invoice is paid, and an unpaid invoice for extra credits never stops the partner: only an unpaid invoice of the contract does (`payment_arrears`).  Available only to partners that have an active paid contract in force with Widgetic (`NO_PAID_CONTRACT` when none is in force) and no overdue contract invoice (`CONTRACT_INVOICE_OVERDUE` while a contract invoice is past its due day). A partner that has run out of credits during its period can buy more at the list price.  An `Idempotency-Key` is required, and it is what makes a retry safe: the same key with the same body returns the invoice already issued, the same key with a different body is refused with 422, and a duplicate that arrives while the first is still running is refused with 409. Use one key per purchase you mean to make, and a new key for the next one. At most 10 requests an hour.  Who may ask: the person who administers the partner, or a Widgetic administrator. A key limited to scopes needs `billing:write`. 
   # @param partner_id Partner ID
@@ -55,36 +55,36 @@ describe 'PartnersApi' do
   # @param request_extra_credits 
   # @param [Hash] opts the optional parameters
   # @return [PartnerExtraCreditsInvoiceResponse]
-  describe 'create_partner_extra_credits_invoice_0 test' do
+  describe 'create_partner_extra_credits_invoice test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_my_partners_0
+  # unit tests for get_my_partners
   # Find the partner you administer
   # Returns the partner (nearly always one) that the signed-in account administers, with the id every other partner route asks for and the standing it is in: `active`, `inactive` (not activated yet), `suspended` (paused, with the reason Widgetic gave) or `payment_arrears` (a contract invoice is past its due date and unpaid, since `overdueSince`; the partner is stopped until it is paid). A partner API key is that account's key, so it reads its own partner here.  An account that administers no partner is not refused: it gets `standing: not_a_partner` and an empty list, so a dashboard can tell \"this is not a partner account\" from \"something failed\".  The call stays open while the partner is paused, not yet active or in payment arrears: that is when its dashboard has to say why. 
   # @param [Hash] opts the optional parameters
   # @return [MyPartnersResponse]
-  describe 'get_my_partners_0 test' do
+  describe 'get_my_partners test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_adapter_connections_0
+  # unit tests for get_partner_adapter_connections
   # See which adapter keys a partner has connected
   # Widget adapters are capabilities a widget can use, and some of them act through a service the account that made the widget has with a provider: an adapter that sends email needs an email provider key, one that sends texts needs an SMS provider key. For the widgets of the customers a partner manages, those keys are the partner's. This lists every key an adapter takes from a partner and whether the partner has connected it.  An empty list means no adapter takes a key from a partner at the moment. The list never contains a key: only whether one is connected and when it was last set.  Connect a key with `setPartnerAdapterConnection`; take it away with `removePartnerAdapterConnection`. A managed customer never holds a key: the widgets of a managed customer use the partner's, and never the personal key of the person who administers the partner.  The caller must be the person who administers the partner (an API key of that account works, with the `partner:read` scope), or a Widgetic administrator. 
   # @param partner_id The partner whose adapter keys to list
   # @param [Hash] opts the optional parameters
-  # @return [GetUserAdapterConnections200Response]
-  describe 'get_partner_adapter_connections_0 test' do
+  # @return [AdapterConnectionListResponse]
+  describe 'get_partner_adapter_connections test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_analytics_by_managed_user_0
+  # unit tests for get_partner_analytics_by_managed_user
   # What each managed user's widgets did
   # Lists every one of your managed users with what their widgets and compositions did in a period: views, interactions and visitors, and how many widgets and compositions they have made. A managed user whose widgets were not viewed is listed too, with zeros. The most viewed come first, and `page.hasMore` says whether more follow.  Only the compositions made for a managed user count for it: file them under the user when you create them (`managedUserId` on `createComposition`), or let the user's editor session do it, which files everything under its user. What a visitor did with a composition that is not filed under anyone is in the summary of the whole account (`getPartnerAnalyticsSummary`) and in no managed user's row.  The period works as it does for `getPartnerAnalyticsSummary`. The caller must be the person who administers the partner (an API key of that account works, with the `partner:read` scope), or a Widgetic administrator. 
   # @param partner_id The partner whose managed users to report on
@@ -94,13 +94,13 @@ describe 'PartnersApi' do
   # @option opts [Integer] :limit How many managed users to list at most
   # @option opts [Integer] :offset How many managed users to skip
   # @return [PartnerAnalyticsByManagedUserResponse]
-  describe 'get_partner_analytics_by_managed_user_0 test' do
+  describe 'get_partner_analytics_by_managed_user test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_analytics_summary_0
+  # unit tests for get_partner_analytics_summary
   # What was done with a partner's published widgets
   # Counts what the visitors of the compositions made through your account did in a period: how many times a composition was **viewed**, how many times a visitor **interacted** with one, and how many different visitors there were. It covers every composition of your account, your own and the ones made for your managed users; narrow it to one managed user with `managedUserId` or `managedUserExternalId` (not both).  The numbers come from the events the embedded widgets send while they are shown (the Widgetic embed SDK sends them by itself), counted when you ask. Only views and interactions are counted; the events that describe a visit (its start, its end, the device and the referrer) are not.  The period runs from `startDate` (included) to `endDate` (not included): the 30 days before now when you give neither, and at most 366 days. A date without a time is midnight UTC at the start of that day, so for all of October give `startDate=2026-10-01` and `endDate=2026-11-01`.  The caller must be the person who administers the partner (an API key of that account works, with the `partner:read` scope), or a Widgetic administrator. 
   # @param partner_id The partner whose widgets to report on
@@ -110,13 +110,13 @@ describe 'PartnersApi' do
   # @option opts [String] :managed_user_id Report only on this managed user (Widgetic's id for the user). Send this or `managedUserExternalId`, not both.
   # @option opts [String] :managed_user_external_id Report only on the managed user you registered with this `externalId` (your own identifier for the user). Send this or `managedUserId`, not both.
   # @return [PartnerAnalyticsSummaryResponse]
-  describe 'get_partner_analytics_summary_0 test' do
+  describe 'get_partner_analytics_summary test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_analytics_timeline_0
+  # unit tests for get_partner_analytics_timeline
   # What was done with a partner's widgets, day by day
   # Counts views, interactions and visitors for each day of a period (UTC days), oldest first, for a chart. Every day of the period is in the list, also one on which nothing happened (all zeros), so the list can be drawn as it is. Narrow it to one managed user with `managedUserId` or `managedUserExternalId` (not both).  The period works as it does for `getPartnerAnalyticsSummary`; `startDate` and `endDate` are best given as dates, so that the first and the last day are whole days. The caller must be the person who administers the partner (an API key of that account works, with the `partner:read` scope), or a Widgetic administrator. 
   # @param partner_id The partner whose widgets to report on
@@ -126,13 +126,13 @@ describe 'PartnersApi' do
   # @option opts [String] :managed_user_id Report only on this managed user (Widgetic's id for the user). Send this or `managedUserExternalId`, not both.
   # @option opts [String] :managed_user_external_id Report only on the managed user you registered with this `externalId`. Send this or `managedUserId`, not both.
   # @return [PartnerAnalyticsTimelineResponse]
-  describe 'get_partner_analytics_timeline_0 test' do
+  describe 'get_partner_analytics_timeline test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_analytics_top_widgets_0
+  # unit tests for get_partner_analytics_top_widgets
   # Which widgets were viewed the most
   # Lists the widgets whose compositions were viewed the most in a period, with their views, interactions, visitors and how many of their compositions were viewed. A widget that nobody viewed or used is not listed. The most viewed come first (then the most used), and at most `limit` are listed. Narrow it to one managed user with `managedUserId` or `managedUserExternalId` (not both).  The period works as it does for `getPartnerAnalyticsSummary`. The caller must be the person who administers the partner (an API key of that account works, with the `partner:read` scope), or a Widgetic administrator. 
   # @param partner_id The partner whose widgets to report on
@@ -143,49 +143,49 @@ describe 'PartnersApi' do
   # @option opts [String] :managed_user_external_id Report only on the managed user you registered with this `externalId`. Send this or `managedUserId`, not both.
   # @option opts [Integer] :limit How many widgets to list at most
   # @return [PartnerAnalyticsTopWidgetsResponse]
-  describe 'get_partner_analytics_top_widgets_0 test' do
+  describe 'get_partner_analytics_top_widgets test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_billing_overview_0
+  # unit tests for get_partner_billing_overview
   # Get comprehensive partner billing overview
   # Retrieves the partner's credits (`operationalCredits`), the partner's contract terms (`partnerCustomization`, the same fields as `getPartnerContract`) and billing integration status. Internal negotiation notes are not part of it. `operationalCredits` is the one account a partner has for its credits: the account of the person who administers it. It holds `balance` (the same balance `getPartnerCreditBalance` reads), `reservedBalance`, `availableBalance` (what a new operation can use) and `recentTransactions` (the ten newest entries of the ledger `getPartnerCreditTransactions` lists). A partner with no administrator has no account, and reads 0 and an empty list. 
   # @param partner_id Partner ID
   # @param [Hash] opts the optional parameters
   # @return [GetPartnerBillingOverview200Response]
-  describe 'get_partner_billing_overview_0 test' do
+  describe 'get_partner_billing_overview test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_contract_0
+  # unit tests for get_partner_contract
   # Get a partner's contract
   # Returns the commercial terms agreed with the partner: price, included credits and storage, billing cycle, commitment, support level, and the dates the contract runs between.  A partner reads its own: the caller must be the person who administers the partner (an API key of that account works), and anyone else is refused with 403 whether or not the partner exists. Widgetic administrators can read any partner's. Responds 404 while no contract has been recorded for the partner, which is the case until Widgetic sets its terms. 
   # @param partner_id The partner whose contract to read
   # @param [Hash] opts the optional parameters
   # @return [PartnerContractResponse]
-  describe 'get_partner_contract_0 test' do
+  describe 'get_partner_contract test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_credit_balance_0
+  # unit tests for get_partner_credit_balance
   # Get partner credit balance
   # Returns the credits the partner has, and how much of that is reserved by operations that are still running. A partner has ONE account for its credits: the account of the person who administers it, the same account its API key acts as. There is nothing else to create or to fund. What its customers' editor sessions and its own API calls spend comes out of that account, and the credits a paid invoice carries are added to it, so this is the same balance `getUserCreditBalance` reads for that person.  A partner with no administrator has no account to hold credits, and reads a balance of 0.  Access: the person who administers the partner, or a Widgetic administrator. 
   # @param partner_id Partner ID
   # @param [Hash] opts the optional parameters
   # @return [AccountCreditBalanceResponse]
-  describe 'get_partner_credit_balance_0 test' do
+  describe 'get_partner_credit_balance test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_credit_transactions_0
+  # unit tests for get_partner_credit_transactions
   # Get partner credit transaction history
   # Lists what happened to the partner's credits, newest first: the entries of the credit ledger of the account of the person who administers it, the one account a partner has for its credits. Every operation that spends credits is a `debit` entry, and the credits an invoice carried arrive as `credit` entries when the invoice is paid, so this is also how the partner's usage is read. It is the same ledger `getUserCreditTransactions` reads for that person.  A partner with no administrator has no account, and an empty ledger.  The page is always bounded: `limit` defaults to 20 and is capped at 100, `offset` defaults to 0.  Access: the person who administers the partner, or a Widgetic administrator. 
   # @param partner_id Partner ID
@@ -193,100 +193,100 @@ describe 'PartnersApi' do
   # @option opts [Integer] :limit Number of transactions to return
   # @option opts [Integer] :offset Number of transactions to skip
   # @option opts [String] :type Only entries of this type, for instance `debit` for the credits spent. The types are listed on `AccountCreditTransaction`. 
-  # @return [GetPartnerCreditTransactions200Response]
-  describe 'get_partner_credit_transactions_0 test' do
+  # @return [AccountCreditTransactionListResponse]
+  describe 'get_partner_credit_transactions test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_data_database_0
+  # unit tests for get_partner_data_database
   # See the Neon database a partner keeps the data of its compositions in
   # Returns the database set with `setPartnerDataDatabase`, without its password: the host, the database and the role, when it last passed the check, and why the latest re-check failed if it did. Responds 404 while the partner has no database of its own, which means the data of its compositions is kept by Widgetic.  The caller must be the person who administers the partner (an API key of that account works, with the `partner:read` scope), or a Widgetic administrator. 
   # @param partner_id The partner whose database to read
   # @param [Hash] opts the optional parameters
   # @return [PartnerDataDatabaseResponse]
-  describe 'get_partner_data_database_0 test' do
+  describe 'get_partner_data_database test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_design_defaults_0
+  # unit tests for get_partner_design_defaults
   # Read partner-wide design defaults
   # @param partner_id 
   # @param [Hash] opts the optional parameters
-  # @return [GetPartnerDesignDefaults200Response]
-  describe 'get_partner_design_defaults_0 test' do
+  # @return [DesignDefaultsResponse]
+  describe 'get_partner_design_defaults test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_entry_context_signing_0
+  # unit tests for get_partner_entry_context_signing
   # See how the context of your embeds is signed
   # Says whether you have a secret to sign the `context` of your embeds with, when it was made, whether the secret it replaced is still accepted, and whether an entry without a valid signature is refused (`required`). The secret itself is never part of the answer: it is shown once, when it is made (`rotatePartnerEntryContextSecret`, which also explains what signing is for and how to sign).  Signing covers the entries written through the gateway into the compositions of your managed users and into those of your own account. The caller must be the person who administers the partner (an API key of that account works, with the `partner:read` scope), or a Widgetic administrator. 
   # @param partner_id The partner whose context signing to read
   # @param [Hash] opts the optional parameters
   # @return [PartnerEntryContextSigningResponse]
-  describe 'get_partner_entry_context_signing_0 test' do
+  describe 'get_partner_entry_context_signing test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_notification_settings_0
+  # unit tests for get_partner_notification_settings
   # Where your notifications go
   # Returns who gets the emails, which events you want by email and by webhook, the address of your webhook, and whether it has a secret to sign with. The secret itself is never returned: it is shown once, when it is made. `events` lists every kind of event there is, for a settings screen.  The caller must be the person who administers the partner (an API key of that account works, with the `partner:read` scope), or a Widgetic administrator. 
   # @param partner_id The partner whose notification settings to read
   # @param [Hash] opts the optional parameters
   # @return [PartnerNotificationSettingsResponse]
-  describe 'get_partner_notification_settings_0 test' do
+  describe 'get_partner_notification_settings test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_storage_destination_0
+  # unit tests for get_partner_storage_destination
   # Get where a partner's uploaded files are stored
   # Returns the partner's storage destination without its secret: the endpoint, bucket, folder and public address, the last four characters of the access key id, when the destination last passed the check, and why the latest re-check failed if it did. Responds 404 while the partner has no destination, which means the partner cannot be activated, its uploads are refused, and no editor session is made for its customers until a destination is set.  The caller must be the person who administers the partner, or a Widgetic administrator. 
   # @param partner_id The partner whose storage destination to read
   # @param [Hash] opts the optional parameters
   # @return [PartnerStorageDestinationResponse]
-  describe 'get_partner_storage_destination_0 test' do
+  describe 'get_partner_storage_destination test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for get_partner_storage_usage_0
+  # unit tests for get_partner_storage_usage
   # What a partner's customers store
-  # Says how many files, and how many bytes, your account keeps, in total and for each of your managed users, and how much of it is in Widgetic's storage and how much in your own storage destination (`setPartnerStorageDestination`). Use it to see which customers store the most, or to charge them for it.  A file is counted for a managed user when it was filed under that user: by naming `managed_user_id` or `managed_user_external_id` when you upload it (`uploadsPost`, or the metadata of a resumable upload), or because it was uploaded through that user's editor session, which files everything under its user. The files that are not filed under anyone (your own, and the ones uploaded without naming a managed user) are the row whose `managedUserId` is null. Deleted files are not counted. To list the files of one managed user, use the `managed_user_id` filter of `uploadsGet`.  The answer is counted when you ask, so it is always current. The groups are ordered by size, the heaviest first, and `page.hasMore` says whether more follow.  The caller must be the person who administers the partner (an API key of that account works, with the `partner:read` scope), or a Widgetic administrator. 
+  # Says how many files, and how many bytes, your account keeps, in total and for each of your managed users, and how much of it is in Widgetic's storage and how much in your own storage destination (`setPartnerStorageDestination`). Use it to see which customers store the most, or to charge them for it.  A file is counted for a managed user when it was filed under that user: by naming `managed_user_id` or `managed_user_external_id` when you upload it (`uploadFile`, or the metadata of a resumable upload), or because it was uploaded through that user's editor session, which files everything under its user. The files that are not filed under anyone (your own, and the ones uploaded without naming a managed user) are the row whose `managedUserId` is null. Deleted files are not counted. To list the files of one managed user, use the `managed_user_id` filter of `listUploads`.  The answer is counted when you ask, so it is always current. The groups are ordered by size, the heaviest first, and `page.hasMore` says whether more follow.  The caller must be the person who administers the partner (an API key of that account works, with the `partner:read` scope), or a Widgetic administrator. 
   # @param partner_id The partner whose storage to report on
   # @param [Hash] opts the optional parameters
   # @option opts [Integer] :limit How many managed users to list at most
   # @option opts [Integer] :offset How many managed users to skip
   # @return [PartnerStorageUsageResponse]
-  describe 'get_partner_storage_usage_0 test' do
+  describe 'get_partner_storage_usage test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for list_partner_notification_deliveries_0
+  # unit tests for list_partner_notification_deliveries
   # How your notifications reached you
   # Lists the sends of your notifications, the newest first: each email to one address and each call to your webhook, with whether it was delivered, when it is tried again if not, how many attempts it had, and why the last one failed. Use it to find out why a webhook of yours did not receive an event.  An email counts as delivered when it was handed to the mail service; a call to your webhook counts as delivered when your endpoint answered with a 2xx status. Anything else is tried again, after 1 minute, then 5 minutes, 30 minutes, 2 hours, 6 hours, 12 hours and a day, eight attempts in all, because your address is read again at each attempt and you may have mended it. Two answers end the delivery at once: `410 Gone` and `413 Payload Too Large`.  The caller must be the person who administers the partner (an API key of that account works, with the `partner:read` scope), or a Widgetic administrator. 
   # @param partner_id The partner whose deliveries to list
   # @param [Hash] opts the optional parameters
   # @option opts [Integer] :limit How many deliveries to list at most
   # @return [PartnerNotificationDeliveryLogResponse]
-  describe 'list_partner_notification_deliveries_0 test' do
+  describe 'list_partner_notification_deliveries test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for list_partner_notifications_0
+  # unit tests for list_partner_notifications
   # What your partner account was told
   # Lists the notifications of a partner, the newest first: the invoices Widgetic issued and their payments, the reminders to pay them, a warning when your credits run low, and the changes to the standing of the account (activated, paused, resumed). It is the same list your dashboard shows, and each entry is what your webhook receives as `data` when you have one (`updatePartnerNotificationSettings`).  A page holds `limit` notifications (20 by default, at most 100). When there are older ones `nextBefore` is set: ask again with it as `before` to get the next page.  The caller must be the person who administers the partner (an API key of that account works, with the `partner:read` scope), or a Widgetic administrator. 
   # @param partner_id The partner whose notifications to list
@@ -294,101 +294,101 @@ describe 'PartnersApi' do
   # @option opts [Integer] :limit How many notifications to list at most
   # @option opts [Time] :before Only the notifications made before this moment. Give the `nextBefore` of the previous page.
   # @return [PartnerNotificationPageResponse]
-  describe 'list_partner_notifications_0 test' do
+  describe 'list_partner_notifications test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for list_partner_presets_0
+  # unit tests for list_partner_presets
   # List the widgets a partner offers as presets
   # Returns the partner's presets, ordered by `position` and then by `key`: the widgets it offers its managed users as starting points. The list is the same for every managed user.  Use a preset in one of two ways: - **Make a composition of it** (the content and design editor): call `createComposition` with the preset's   `widgetId` and the managed user. The widget itself stays yours; a composition is the user's own content. - **Give the user a copy to build on** (the widget creator): call `copyPresetForManagedUser`. The user gets   a widget and a canvas of their own.  Presets are not the same as the widgets Widgetic puts on every new Widgetic account. Those are chosen by Widgetic and are copied at sign-up. A preset here is yours, and is copied only when you ask.  The caller must be the person who administers the partner (an API key of that account works), or a Widgetic administrator. 
   # @param partner_id The partner whose presets to list
   # @param [Hash] opts the optional parameters
   # @return [ListPartnerPresets200Response]
-  describe 'list_partner_presets_0 test' do
+  describe 'list_partner_presets test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for list_partner_workflow_presets_0
+  # unit tests for list_partner_workflow_presets
   # List the workflows a partner offers as places to start
   # The partner's starting points, ordered by `position` and then by `key`: the published workflows it offers its managed users when they make a new workflow. Each says whether people can start from it now and, when they cannot, why. The list is the same for every managed user, and a managed user is shown only what is available.  A starting point is one of the partner account's own published workflows, built from compositions the account made for itself (not for a customer or a team) and from widgets the partner already offers as presets (`setPartnerPreset`), and it uses at most 10 widgets. A partner offers up to 50.  The caller must be the person who administers the partner (an API key of that account works), or a Widgetic administrator. 
   # @param partner_id The partner whose starting points to list
   # @param [Hash] opts the optional parameters
   # @return [ListPartnerWorkflowPresets200Response]
-  describe 'list_partner_workflow_presets_0 test' do
+  describe 'list_partner_workflow_presets test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for remove_partner_adapter_connection_0
+  # unit tests for remove_partner_adapter_connection
   # Remove an adapter key from a partner
   # Removes a key an adapter was given. The adapter stops working for the widgets of the partner's customers that need it: their visitors are told the feature is unavailable. Nothing else of the widgets changes, and connecting a key again brings them back.  Removing a key that is not connected answers 200 with `removed: false`: the state asked for is the state it is in. A key of an adapter that has since been retired from the catalog can still be removed.  This needs an API key with full access. The caller must be the person who administers the partner, or a Widgetic administrator. 
   # @param partner_id The partner that keeps the key
   # @param adapter_id The adapter the key is for
   # @param credential_key The key's name within the adapter
   # @param [Hash] opts the optional parameters
-  # @return [RemoveUserAdapterConnection200Response]
-  describe 'remove_partner_adapter_connection_0 test' do
+  # @return [AdapterConnectionRemovalResponse]
+  describe 'remove_partner_adapter_connection test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for remove_partner_data_database_0
+  # unit tests for remove_partner_data_database
   # Stop keeping the data of a partner's compositions in its own database
   # Removes the partner's database from Widgetic: Widgetic forgets the connection string, and from then on the data of the partner's compositions is kept in Widgetic's database again. Nothing in your database is deleted.  Removing is refused with 409 `PARTNER_DATABASE_HOLDS_DATA` while any composition of the partner keeps its data in your database: it would read as empty from then on, and what it holds would stay where nothing reads it. Delete the compositions you no longer need, or keep the database. If Widgetic cannot check what your database holds (it cannot be reached) the answer is 503 `PARTNER_DATABASE_UNAVAILABLE`; check it with `verifyPartnerDataDatabase`, or set the same database again to repair its connection.  Removing a database the partner does not have is not an error: the answer is `removed: false`.  This needs an API key with full access. The caller must be the person who administers the partner, or a Widgetic administrator. 
   # @param partner_id The partner whose database to remove
   # @param [Hash] opts the optional parameters
   # @return [PartnerDataDatabaseRemovalResponse]
-  describe 'remove_partner_data_database_0 test' do
+  describe 'remove_partner_data_database test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for remove_partner_preset_0
+  # unit tests for remove_partner_preset
   # Take a widget off the partner's presets
   # Removes the preset under `key`. The widget itself is not touched, and neither are the copies and the compositions already made from it.  Removing a preset the partner does not have is not an error: the answer is `removed: false`. 
   # @param partner_id The partner whose preset to remove
   # @param key The key of the preset to remove
   # @param [Hash] opts the optional parameters
   # @return [PartnerPresetRemovalResponse]
-  describe 'remove_partner_preset_0 test' do
+  describe 'remove_partner_preset test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for remove_partner_storage_destination_0
+  # unit tests for remove_partner_storage_destination
   # Stop storing a partner's uploaded files in its own bucket
   # Removes the partner's storage destination. Partner storage is not optional, so after this every upload of the account, on any route, and the uploads of your customers' editor sessions are refused (409 `PARTNER_STORAGE_REQUIRED`) until a destination is set again, and no editor session can be made. Files already in the partner's bucket are not touched and are not moved: they stay where they are, at the addresses they were given.  Removing a destination the partner does not have is not an error: the answer is `removed: false`.  The caller must be the person who administers the partner, or a Widgetic administrator. 
   # @param partner_id The partner whose storage destination to remove
   # @param [Hash] opts the optional parameters
   # @return [PartnerStorageRemovalResponse]
-  describe 'remove_partner_storage_destination_0 test' do
+  describe 'remove_partner_storage_destination test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for remove_partner_workflow_preset_0
+  # unit tests for remove_partner_workflow_preset
   # Stop offering a workflow as a place to start
   # Removes the starting point under `key`. The workflow itself is not touched, and neither are the workflows people already started from it.  Removing a starting point the partner does not offer is not an error: the answer is `removed: false`. 
   # @param partner_id The partner whose starting point to remove
   # @param key The key of the starting point to remove
   # @param [Hash] opts the optional parameters
   # @return [RemovePartnerWorkflowPreset200Response]
-  describe 'remove_partner_workflow_preset_0 test' do
+  describe 'remove_partner_workflow_preset test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for replay_partner_notification_delivery_0
+  # unit tests for replay_partner_notification_delivery
   # Send a webhook delivery again
   # Sends one earlier **webhook** delivery again to your **current** webhook address, with the same event `id` (`webhook-id`) as the original notification so a receiver that remembers ids can ignore a duplicate, and a new `createdAt` and signature made with your current secret. The attempt is recorded in the delivery log as a new row that points at the delivery you replayed.  Set a webhook address (and secret) under notification settings before you replay. Changing the settings needs an API key with full access. The caller must be the person who administers the partner, or a Widgetic administrator. 
   # @param partner_id The partner whose delivery to replay
@@ -396,39 +396,39 @@ describe 'PartnersApi' do
   # @param idempotency_key Required: a call without it is refused with `400`. A key of your own that names this one request; a UUID is ideal. It is 8 to 50 characters of letters, digits, `-` and `_`. Send the same key again when you retry (after a timeout, a dropped connection or a `5xx`) and the call is carried out once: the retry gets the first answer back, marked `X-Idempotency-Cached: true`. The same key with a different body is refused with `422`, and a retry that arrives while the first call is still running with `409` (see `Retry-After`).
   # @param [Hash] opts the optional parameters
   # @return [PartnerNotificationDeliveryResponse]
-  describe 'replay_partner_notification_delivery_0 test' do
+  describe 'replay_partner_notification_delivery test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for rotate_partner_entry_context_secret_0
+  # unit tests for rotate_partner_entry_context_secret
   # Make a secret to sign the context of your embeds
   # Makes a secret to sign the `context` of your embeds with, and returns it in `secret`: **keep it now, it is shown once** and cannot be read again. Keep it on your server only: whoever holds it can write contexts your compositions accept. Call this again to make a new secret; the one it replaces is still accepted for a day, so that your server can switch without an entry being refused (making another within that day ends the overlap with the first).  **What signing is for.** `<widgetic composition-id=\"...\" context='{\"customerId\":\"c_42\"}'>` hands attribution to a widget, which sends it with every entry it saves. The page is yours but the browser is the visitor's: anybody can change that attribute and file an entry under another customer's id. When your server signs the context, the gateway refuses an entry whose context was changed, and the entries you keep hold attribution your server wrote.  **How to sign** (on your server, for each page you render):  1. Take the context to give the widget. It may hold text and whole numbers only (within ±2^53, written without    a fraction or an exponent). 2. Choose when the signature stops being good: `widgetic_exp`, in seconds since 1970 (UTC), no more than    seven days from now. A minute of difference between clocks is forgiven. 3. Write the text to sign, with no spaces except those inside values:    `widgetic-context.v1.<compositionId>.<widgetic_exp>.<json>`. `<compositionId>` is the id of the composition    in lower case. `<json>` is the context as JSON with the keys in character-code order (so `Z` comes before    `a`, and `10` before `9`), no spaces, strings escaped as JSON escapes them, and the two keys of the    signature left out. 4. Sign that text: HMAC-SHA256 with the 32 bytes the secret stands for (the base64 text after `ctxsec_`), and    write the result as base64url without padding. 5. Give the widget the context with two keys added: `widgetic_exp` and `widgetic_sig` (the signature). The whole    attribute, the two keys included, stays within the limits of any context: at most 20 keys, 2048 bytes of    JSON, strings up to 500 characters. The two keys take two of the 20 keys and 87 bytes of the 2048.  A test vector, to check your code against before you rely on it. Secret `ctxsec_AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8=` (the bytes 0 to 31), composition `7c9e6679-7425-40de-944b-e07fc1f90ae7`, `widgetic_exp` 1792000000 and context `{\"customerId\":\"c_42\",\"plan\":\"pro\",\"seats\":3}` sign the text `widgetic-context.v1.7c9e6679-7425-40de-944b-e07fc1f90ae7.1792000000.{\"customerId\":\"c_42\",\"plan\":\"pro\",\"seats\":3}` and give the signature `j6g7151F54tl9C8oEY9levaYSppHME4fAPZ7WPwL8C8`. (The secret is the example's, not a real one.)  **What the gateway does with an entry.** When you have a secret, an entry whose context carries a signature is checked: a signature that does not match is refused with 403 `CONTEXT_SIGNATURE_INVALID`, and one that is past `widgetic_exp` with 403 `CONTEXT_SIGNATURE_EXPIRED`. When you also require signatures (`updatePartnerEntryContextSigning`) an entry whose context carries none is refused with 403 `CONTEXT_SIGNATURE_REQUIRED`. The two keys are taken out before the entry is stored or announced: your entries and your `entry.created` events hold the context you wrote. A change you make reaches every part of the gateway within a minute.  **What it does not do.** A signed context that has been seen (a page's source is public) can be sent again by anyone until `widgetic_exp`; when you must not accept the same context twice, put a value that is new for each page view in it (a `submissionId` you made up) and keep the ones you have seen. The signature covers the entries that reach Widgetic's gateway: a row that gets into a table another way (your own code writing straight into a database you brought, or the record calls of the composition's owner) does not pass through it, and carries no context.  Retry this call with the same `Idempotency-Key` if its answer was lost: the answer, secret included, is then given again, and no second secret is made. This needs an API key with full access. The caller must be the person who administers the partner, or a Widgetic administrator. 
   # @param partner_id The partner whose secret to make
   # @param idempotency_key Required: a call without it is refused with `400`. A key of your own that names this one request; a UUID is ideal. It is 8 to 50 characters of letters, digits, `-` and `_`. Send the same key again when you retry (after a timeout, a dropped connection or a `5xx`) and the call is carried out once: the retry gets the first answer back, marked `X-Idempotency-Cached: true`. The same key with a different body is refused with `422`, and a retry that arrives while the first call is still running with `409` (see `Retry-After`).
   # @param [Hash] opts the optional parameters
   # @return [PartnerEntryContextSecretResponse]
-  describe 'rotate_partner_entry_context_secret_0 test' do
+  describe 'rotate_partner_entry_context_secret test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for rotate_partner_webhook_secret_0
+  # unit tests for rotate_partner_webhook_secret
   # Make a new secret for your webhook
   # Makes a new secret to sign your webhook with, and returns it in `webhookSecret`: **keep it now, it is shown once** and cannot be read again. Use it when the secret was lost, or may have leaked.  The secret you had keeps signing beside the new one for a day, so that your receiver can switch without a call being rejected: during that day each call carries two signatures (see `updatePartnerNotificationSettings` for how they are verified). Rotating again within the day ends the overlap with the first secret.  Retry this call with the same `Idempotency-Key` if its answer was lost: the answer, secret included, is then given again, and no second secret is made.  This needs an API key with full access. The caller must be the person who administers the partner, or a Widgetic administrator. 
   # @param partner_id The partner whose webhook secret to replace
   # @param idempotency_key Required: a call without it is refused with `400`. A key of your own that names this one request; a UUID is ideal. It is 8 to 50 characters of letters, digits, `-` and `_`. Send the same key again when you retry (after a timeout, a dropped connection or a `5xx`) and the call is carried out once: the retry gets the first answer back, marked `X-Idempotency-Cached: true`. The same key with a different body is refused with `422`, and a retry that arrives while the first call is still running with `409` (see `Retry-After`).
   # @param [Hash] opts the optional parameters
   # @return [PartnerNotificationSettingsChangeResponse]
-  describe 'rotate_partner_webhook_secret_0 test' do
+  describe 'rotate_partner_webhook_secret test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for send_partner_notification_test_event_0
+  # unit tests for send_partner_notification_test_event
   # Send a test event to your webhook
   # Sends ONE signed call, right now, to the webhook address you saved under notification settings, with a sample of what an event of the type you name carries, and answers how it went: whether your receiver answered with a 2xx status, which status, how long it took, and why not when it did not arrive. Use it to write and try your receiver (above all the signature check) before a real event happens.  The call is made like every other: it is signed with your current secret (and the previous one while a rotation overlaps), it carries the headers `webhook-id`, `webhook-timestamp`, `webhook-signature` and `x-widgetic-event` (the event type), and its body is `{ \"id\", \"type\", \"createdAt\", \"partnerId\", \"data\" }`. Three things differ. `id` starts with `evt_test_` and is new every time, so a receiver that remembers ids can tell a test from an event and drop it. `data` holds made-up values of the shape a real event of that type carries (`PartnerNotification` describes each), never anything about your account. And the call is made once: it is not tried again, nothing is stored, and it appears neither in the delivery log nor in the notification list.  It is sent whatever `webhookEvents` says: a test is not filtered by what you subscribed to. The answer is 200 whether or not your receiver took the call (read `delivered`); a call that gets no answer within ten seconds is given up and reported as a `timeout`.  A webhook address and a signing secret must be saved first (`updatePartnerNotificationSettings`); until then the answer is 409. This needs an API key with full access, and `Idempotency-Key` is required: a retry with the same key gets the first answer back and no second call is made. The caller must be the person who administers the partner, or a Widgetic administrator. Five tests a minute. 
   # @param partner_id The partner whose webhook to try
@@ -436,13 +436,13 @@ describe 'PartnersApi' do
   # @param partner_notification_test_event_request 
   # @param [Hash] opts the optional parameters
   # @return [PartnerNotificationTestEventResultResponse]
-  describe 'send_partner_notification_test_event_0 test' do
+  describe 'send_partner_notification_test_event test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for set_partner_adapter_connection_0
+  # unit tests for set_partner_adapter_connection
   # Connect an adapter key to a partner
   # Gives an adapter the key it needs to act through a service the partner has an account with, for the widgets of the customers the partner manages. Take the `adapterId` and `credentialKey` from `getPartnerAdapterConnections`. Saving a key that is already connected replaces it.  **What Widgetic does with it.** The key is stored encrypted, bound to this partner, this adapter and this credential, so that a stored value cannot be moved to another. It is never returned, never logged and never shown to a visitor of a widget or to your customers. A server of Widgetic opens it for the one call a widget makes through the adapter, uses it to call the provider on the partner's behalf, and discards it. To cut that off, remove the key here, or revoke it with the provider.  **What is checked.** That the adapter exists and takes this credential, that a partner may keep it (some are for an owner only) and that the text is one line of at most 2048 characters. Whether the provider accepts the key is not checked here: it shows the first time a widget uses it.  **An address that has to be confirmed.** Some credentials are not a key but the email address Widgetic sends a widget's messages to (`confirmation: email_code` in `getPartnerAdapterConnections`). Saving one checks that it is one email address and emails a six-digit code to it; the answer says `awaitingConfirmation: true`, and nothing is sent to the address until the code is given back with `confirmPartnerAdapterConnection`. Saving the same address again before it is confirmed emails a new code (not sooner than a minute after the last); saving the address that is already confirmed changes nothing. If the code cannot be emailed, nothing is saved.  A widget whose adapter has no key connected, or whose address is not confirmed yet, is not charged and does not run that adapter: its visitors are told the feature is unavailable, and the partner is told once a day what to do.  This needs an API key with full access. The caller must be the person who administers the partner, or a Widgetic administrator. A retry is harmless: saving the same key twice only refreshes when it was set. 
   # @param partner_id The partner that keeps the key
@@ -450,40 +450,40 @@ describe 'PartnersApi' do
   # @param credential_key The key's name within the adapter
   # @param set_adapter_connection_request 
   # @param [Hash] opts the optional parameters
-  # @return [SetUserAdapterConnection200Response]
-  describe 'set_partner_adapter_connection_0 test' do
+  # @return [AdapterConnectionResponse]
+  describe 'set_partner_adapter_connection test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for set_partner_data_database_0
+  # unit tests for set_partner_data_database
   # Keep the data of a partner's compositions in a Neon database of its own
   # Points the partner at a Neon database of its own. From then on, what visitors leave in the compositions of the partner's managed users, and of the compositions made in the partner's own account (the votes, ratings, answers and form submissions of the widgets that collect them), is stored in that database and nowhere else. Widgetic's own database is not used for them any more, and nothing of it is copied there.  **What to give.** The connection string of a Neon database and a role made for this, as Neon shows it under *Connect* (`postgresql://<role>:<password>@ep-<name>.<region>.aws.neon.tech/<database>`). Only Neon databases are accepted; a string for any other host is refused with 400. What the database needs: - an empty database of its own, so that nothing else of yours shares it. Widgetic makes one schema in it for   each composition (named `comp_` followed by the composition's id). In that schema go the tables the widget   declares for what its visitors leave, and two small tables of Widgetic's own, whose names start with   `_widgetic_`: the context a host page sent with an entry, and how far Widgetic has read the entries to tell   you about new ones. It touches nothing else; - a role that may create schemas and tables in it (the CREATE privilege on the database). The role Neon makes   with a project has it. A role made in the Neon console can also read and write every other database of the   same project, so if you keep other data in Neon give Widgetic a project of its own, or make the role with   SQL (`CREATE ROLE ... LOGIN PASSWORD ...`) and grant it only the CREATE privilege on this database; - connections from anywhere: Widgetic's addresses are not fixed, so a Neon project that only accepts   connections from an allow list of addresses cannot be used. A suspended compute is fine: it wakes on the   first request.  **It is checked before it is saved.** Widgetic makes a schema in your database, creates a table in it, writes a row, reads it back, and removes the schema again, all in one step, so that nothing is left if anything fails. If it cannot be done nothing is saved and the answer is 422 `PARTNER_DATABASE_UNVERIFIED`: `details.reason` says why (`INVALID_CREDENTIALS`, `DATABASE_NOT_FOUND`, `ACCESS_DENIED`, `ACCESS_BLOCKED`, `ENDPOINT_NOT_FOUND`, `ENDPOINT_UNREACHABLE`, `TIMEOUT`, `READ_ONLY`, `RATE_LIMITED`, `DATABASE_UNAVAILABLE`, `PROBE_MISMATCH` or `DATABASE_ERROR`) and `message` says what to do.  **Existing data does not move.** The data of a composition lives in one database. If any composition of the partner already keeps data somewhere else (in Widgetic's database, or in the database you had set), and the new database does not hold it, the change is refused with 409 `PARTNER_DATABASE_HOLDS_DATA` and nothing is changed: those compositions would read as empty from then on. `details.compositionsWithData` says how many. Set your database before your customers collect data, or delete the compositions you no longer need. Saving the same database again (a new password) moves nothing and is never refused.  **It is never a fallback.** Once a database is set, a request that needs it while it cannot be used (the password was changed, the project was deleted) is refused with 503 `PARTNER_DATABASE_UNAVAILABLE`. What the visitor sent is not stored with Widgetic instead. Fix the connection and set the database again, or check it with `verifyPartnerDataDatabase`.  **When it takes effect.** A change reaches every part of Widgetic within about a minute.  **What Widgetic keeps.** The connection string is stored encrypted and is never returned or logged; a response shows the host, the database and the role, never the password. Widgetic's servers open it to read and write the data of your compositions while they handle a request for it. To cut that off, change the role's password in Neon: the compositions stop saving until you set the new string.  This needs an API key with full access. The caller must be the person who administers the partner, or a Widgetic administrator. A retry is harmless: saving the same database twice only refreshes when it was checked and saved. 
   # @param partner_id The partner whose database to set
   # @param set_partner_data_database_request 
   # @param [Hash] opts the optional parameters
   # @return [PartnerDataDatabaseResponse]
-  describe 'set_partner_data_database_0 test' do
+  describe 'set_partner_data_database test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for set_partner_design_defaults_0
+  # unit tests for set_partner_design_defaults
   # Set or clear partner-wide design defaults
   # Send `{ \"design\": { ... } }` or `{ \"design\": null }` to remove. New compositions merge this layer over the widget base and under each managed user's default and the request body. 
   # @param partner_id 
   # @param set_partner_design_defaults_request 
   # @param [Hash] opts the optional parameters
-  # @return [GetPartnerDesignDefaults200Response]
-  describe 'set_partner_design_defaults_0 test' do
+  # @return [DesignDefaultsResponse]
+  describe 'set_partner_design_defaults test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for set_partner_preset_0
+  # unit tests for set_partner_preset
   # Make a widget a preset, or replace a preset
   # Offers one of the partner's own widgets as a preset under `key`. If the partner already has a preset under that key it is replaced, so sending the same request twice is safe. Saving replaces the whole preset: a `title`, `description` or `position` you leave out goes back to its default.  Keys are 1 to 64 characters: lowercase letters, digits, hyphens and underscores, the first a letter or a digit (`rating`, `quiz-3`).  The widget must belong to the partner's account; a widget that does not exist and one that belongs to somebody else are refused in the same way (404 `PRESET_WIDGET_NOT_FOUND`). A widget is a preset under at most one key (409 `PRESET_WIDGET_ALREADY_USED`; `details.key` says which), and an account can have at most 100 presets (409 `PRESET_LIMIT_REACHED`).  Later changes to the widget reach new copies and new compositions; copies made earlier are not touched. Deleting the widget removes its preset. 
   # @param partner_id The partner whose preset to set
@@ -491,26 +491,26 @@ describe 'PartnersApi' do
   # @param set_partner_preset_request 
   # @param [Hash] opts the optional parameters
   # @return [PartnerPresetResponse]
-  describe 'set_partner_preset_0 test' do
+  describe 'set_partner_preset test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for set_partner_storage_destination_0
+  # unit tests for set_partner_storage_destination
   # Set where a partner's uploaded files are stored
-  # Points the partner at a bucket of its own on an S3-compatible service (Cloudflare R2, Amazon S3, Wasabi, MinIO and the like). From then on, every file the account that administers the partner stores is kept in that bucket instead of with Widgetic, whichever way it arrives: a file sent with `uploadsPost` (with an API key, an SDK token, an editor session or from the Widgetic website), a resumable upload, the media library, and the files the agent tools and the MCP server save. It takes none of the account's storage allowance, and its `url` is served from `publicBaseUrl`. The chunks of a resumable upload wait in Widgetic's temporary staging area until it is completed and are removed then: the finished file is stored in your bucket and nowhere else.  A destination is required. Partner storage is not optional: your customers' files, and your own however they arrive, are kept in this destination and nowhere else. An editor session (`createManagedUserEditorSession`) of any surface cannot be made until a destination is set (409 `PARTNER_STORAGE_REQUIRED`), a destination removed later stops the uploads of the sessions already made (the same 409), and your own upload with no destination (on any route, including a resumable upload, which is refused when it is started) is refused in the same way instead of being stored with Widgetic. A partner cannot be activated until it has a destination that works.  The destination is checked before it is saved. Widgetic writes a small test file under `<keyPrefix>widgetic-check/`, reads it back from `<publicBaseUrl>/<its key>`, and deletes it. If any step fails nothing is saved and the answer is 422 `STORAGE_DESTINATION_UNVERIFIED`: `details.step` says where (`endpoint`, `write` or `public_read`), `details.reason` says why, and `param` names the field most likely to be wrong.  What the bucket needs: - an access key that may put objects into it (it may also delete objects, which lets the test file be   cleaned up, but that is not required); - its files publicly readable at `publicBaseUrl`, either because the bucket is public or through a CDN.  The secret access key is stored encrypted and is never returned or logged; a response shows only the last four characters of the access key id (`accessKeyHint`). Saving replaces the whole destination, so send every field again, including the secret. Files already stored stay where they are, and keep working for as long as that bucket stays publicly readable.  Once a destination is set, an upload is never stored with Widgetic instead: when the destination cannot be used the upload is refused with 503 `STORAGE_DESTINATION_UNAVAILABLE`, and when the bucket rejects the file with 502 `STORAGE_DESTINATION_WRITE_FAILED`.  The caller must be the person who administers the partner (an API key of that account works); anyone else is refused with 403 whether or not the partner exists. Widgetic administrators can set any partner's. 
+  # Points the partner at a bucket of its own on an S3-compatible service (Cloudflare R2, Amazon S3, Wasabi, MinIO and the like). From then on, every file the account that administers the partner stores is kept in that bucket instead of with Widgetic, whichever way it arrives: a file sent with `uploadFile` (with an API key, an SDK token, an editor session or from the Widgetic website), a resumable upload, the media library, and the files the agent tools and the MCP server save. It takes none of the account's storage allowance, and its `url` is served from `publicBaseUrl`. The chunks of a resumable upload wait in Widgetic's temporary staging area until it is completed and are removed then: the finished file is stored in your bucket and nowhere else.  A destination is required. Partner storage is not optional: your customers' files, and your own however they arrive, are kept in this destination and nowhere else. An editor session (`createManagedUserEditorSession`) of any surface cannot be made until a destination is set (409 `PARTNER_STORAGE_REQUIRED`), a destination removed later stops the uploads of the sessions already made (the same 409), and your own upload with no destination (on any route, including a resumable upload, which is refused when it is started) is refused in the same way instead of being stored with Widgetic. A partner cannot be activated until it has a destination that works.  The destination is checked before it is saved. Widgetic writes a small test file under `<keyPrefix>widgetic-check/`, reads it back from `<publicBaseUrl>/<its key>`, and deletes it. If any step fails nothing is saved and the answer is 422 `STORAGE_DESTINATION_UNVERIFIED`: `details.step` says where (`endpoint`, `write` or `public_read`), `details.reason` says why, and `param` names the field most likely to be wrong.  What the bucket needs: - an access key that may put objects into it (it may also delete objects, which lets the test file be   cleaned up, but that is not required); - its files publicly readable at `publicBaseUrl`, either because the bucket is public or through a CDN.  The secret access key is stored encrypted and is never returned or logged; a response shows only the last four characters of the access key id (`accessKeyHint`). Saving replaces the whole destination, so send every field again, including the secret. Files already stored stay where they are, and keep working for as long as that bucket stays publicly readable.  Once a destination is set, an upload is never stored with Widgetic instead: when the destination cannot be used the upload is refused with 503 `STORAGE_DESTINATION_UNAVAILABLE`, and when the bucket rejects the file with 502 `STORAGE_DESTINATION_WRITE_FAILED`.  The caller must be the person who administers the partner (an API key of that account works); anyone else is refused with 403 whether or not the partner exists. Widgetic administrators can set any partner's. 
   # @param partner_id The partner whose storage destination to set
   # @param set_partner_storage_destination_request 
   # @param [Hash] opts the optional parameters
   # @return [PartnerStorageDestinationResponse]
-  describe 'set_partner_storage_destination_0 test' do
+  describe 'set_partner_storage_destination test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for set_partner_workflow_preset_0
+  # unit tests for set_partner_workflow_preset
   # Offer a workflow as a place to start, or replace what a key offers
   # Offers one of the partner account's own published workflows to its managed users under `key`. If the partner already offers something under that key it is replaced, so sending the same request twice is safe. Saving replaces the whole starting point: a `title`, `description` or `position` you leave out goes back to its default.  Keys are 1 to 64 characters: lowercase letters, digits, hyphens and underscores, the first a letter or a digit.  A workflow is offered once. What people get is the workflow's live version as it is when they start, so publishing the workflow changes what new starts get; workflows people already started are never touched. The offer is refused, and `error.details.reason` says why, when the workflow:  - is not the partner account's own (a workflow of a team or of a customer, or of somebody else), or does not exist:   404, the same for both; - is archived (409 `workflow_archived`), or was never published (409 `workflow_not_published`); - shows no composition (422 `workflow_empty`), or a block shows a composition made for a customer or a team   (422 `composition_not_own`); - chains more than 10 widgets (422 `too_many_widgets`), or a widget that the partner does not offer as a preset   (422 `widget_not_preset`; `error.details.widgets` lists them, each with its `id` and `name`, so they can be offered   first with `setPartnerPreset`); - is already offered under another key (409 `workflow_already_offered`; `error.details.key` says which), or the   partner already offers 50 (409 `too_many_presets`).  The caller must be the person who administers the partner (an API key of that account works), or a Widgetic administrator, who offers the partner's workflow on its behalf. 
   # @param partner_id The partner whose starting point to set
@@ -518,13 +518,13 @@ describe 'PartnersApi' do
   # @param offer_workflow_preset_request 
   # @param [Hash] opts the optional parameters
   # @return [SetPartnerWorkflowPreset200Response]
-  describe 'set_partner_workflow_preset_0 test' do
+  describe 'set_partner_workflow_preset test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for update_partner_entry_context_signing_0
+  # unit tests for update_partner_entry_context_signing
   # Require a signed context, or stop requiring it
   # Chooses what the gateway does with an entry whose `context` carries no valid signature.  With `required: false` (the default) an entry that carries a signature is checked and refused when the signature is wrong or out of date, and an entry that carries none is accepted, as it always was. With `required: true` an entry without a valid signature is refused with 403 `CONTEXT_SIGNATURE_REQUIRED`: use it once every page of yours that embeds a composition signs its context.  Signatures cannot be required before you have made a secret (`rotatePartnerEntryContextSecret`): the answer is 409, so that you cannot lock your own compositions out of taking entries. The change reaches every part of the gateway within a minute.  Saving the same choice twice leaves the same state, so a retry is harmless and `Idempotency-Key` is optional. This needs an API key with full access. The caller must be the person who administers the partner, or a Widgetic administrator. 
   # @param partner_id The partner whose context signing to change
@@ -532,13 +532,13 @@ describe 'PartnersApi' do
   # @param [Hash] opts the optional parameters
   # @option opts [String] :idempotency_key Optional: without it the call is carried out every time it is sent. A key of your own that names this one request; a UUID is ideal. It is 8 to 50 characters of letters, digits, `-` and `_`. Send the same key again when you retry (after a timeout, a dropped connection or a `5xx`) and the call is carried out once: the retry gets the first answer back, marked `X-Idempotency-Cached: true`. The same key with a different body is refused with `422`, and a retry that arrives while the first call is still running with `409` (see `Retry-After`).
   # @return [PartnerEntryContextSigningResponse]
-  describe 'update_partner_entry_context_signing_0 test' do
+  describe 'update_partner_entry_context_signing test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for update_partner_notification_settings_0
+  # unit tests for update_partner_notification_settings
   # Choose where your notifications go
   # Changes who gets the emails, which events you want by email and by webhook, and the address of your webhook. A key you leave out of the body is left as it was; send only what changes.  **Email.** `emailRecipients` is the list of addresses (at most five). While it is empty the emails about invoices go to the billing emails of your billing profile (your contact email when there are none), and the others to your contact email. The events about money and about the standing of your account are always emailed, whatever `emailEvents` says; it narrows the others.  **Webhook.** `webhookUrl` is where Widgetic sends a signed `POST` for each event, so that your own system can act on it (mark an invoice paid, warn your team that credits are low). The address must be `https` on the standard port, on a public site, and must not redirect. Setting an address when you have no secret yet makes one, and the answer carries it as `webhookSecret`: **keep it now, it is shown once**. `webhookEvents` narrows what is sent.  Each call has a JSON body, `{ \"id\": \"evt_...\", \"type\": \"invoice.paid\", \"createdAt\": \"...\", \"partnerId\": \"...\", \"data\": { ... } }` (`data` is the `data` of `PartnerNotification`), and these headers: `webhook-id` (the same as `id`, and the same on every retry), `webhook-timestamp` (seconds since 1970) and `webhook-signature` (`v1,` and a base64 HMAC-SHA256). It is the Standard Webhooks scheme, so any of its libraries verifies it. By hand: take your secret without the `whsec_` prefix, decode it from base64, and sign the text `<webhook-id>.<webhook-timestamp>.<the raw body>` with it; the header holds `v1,<base64 of the result>` (two signatures separated by a space while a rotated secret overlaps). Reject a `webhook-timestamp` that is more than five minutes old.  Answer with a 2xx status within ten seconds. Anything else is tried again, eight attempts in all over about two days (`listPartnerNotificationDeliveries` shows each). Delivery is at least once: if your answer was lost the same event arrives again with the same `id`, so drop what you have already handled by it.  Changing the settings needs an API key with full access: they decide where your notifications go. The caller must be the person who administers the partner, or a Widgetic administrator. 
   # @param partner_id The partner whose notification settings to change
@@ -546,31 +546,31 @@ describe 'PartnersApi' do
   # @param [Hash] opts the optional parameters
   # @option opts [String] :idempotency_key Optional: without it the call is carried out every time it is sent. A key of your own that names this one request; a UUID is ideal. It is 8 to 50 characters of letters, digits, `-` and `_`. Send the same key again when you retry (after a timeout, a dropped connection or a `5xx`) and the call is carried out once: the retry gets the first answer back, marked `X-Idempotency-Cached: true`. The same key with a different body is refused with `422`, and a retry that arrives while the first call is still running with `409` (see `Retry-After`).
   # @return [PartnerNotificationSettingsChangeResponse]
-  describe 'update_partner_notification_settings_0 test' do
+  describe 'update_partner_notification_settings test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for verify_partner_data_database_0
+  # unit tests for verify_partner_data_database
   # Check that a partner's own database still works
   # Runs the same check as `setPartnerDataDatabase` against the database already saved: a schema is made in it, a table created, a row written and read back, and the schema removed again. Use it after changing the role's password or the project's settings in Neon, or when saving is failing with 503 `PARTNER_DATABASE_UNAVAILABLE`.  The result is recorded either way. A pass refreshes `verifiedAt` and clears `lastVerificationError`; a failure answers 422 `PARTNER_DATABASE_UNVERIFIED` and is recorded in `lastVerificationError` and `lastVerificationFailedAt`, so the database shows what went wrong the next time it is read. A failed check does not remove the database. `details.reason` is one of the reasons `setPartnerDataDatabase` lists, or `STORED_STRING_UNREADABLE` when the connection string Widgetic stored can no longer be read: set the database again, with its connection string.  This needs an API key with full access. The caller must be the person who administers the partner, or a Widgetic administrator. 
   # @param partner_id The partner whose database to check
   # @param [Hash] opts the optional parameters
   # @return [PartnerDataDatabaseResponse]
-  describe 'verify_partner_data_database_0 test' do
+  describe 'verify_partner_data_database test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end
   end
 
-  # unit tests for verify_partner_storage_destination_0
+  # unit tests for verify_partner_storage_destination
   # Check that a partner's storage destination still works
   # Runs the same check as `setPartnerStorageDestination` against the destination already saved: a test file is written, read back from the public address and deleted. Use it after rotating a key or changing a bucket policy, or when uploads are failing with 502 or 503.  The result is recorded either way. A pass refreshes `verifiedAt` and clears `lastVerificationError`; a failure answers 422 `STORAGE_DESTINATION_UNVERIFIED` and is recorded in `lastVerificationError` and `lastVerificationFailedAt`, so the destination shows what went wrong the next time it is read. A failed check does not remove the destination or stop uploads from using it.  The caller must be the person who administers the partner, or a Widgetic administrator. 
   # @param partner_id The partner whose storage destination to check
   # @param [Hash] opts the optional parameters
   # @return [PartnerStorageDestinationResponse]
-  describe 'verify_partner_storage_destination_0 test' do
+  describe 'verify_partner_storage_destination test' do
     it 'should work' do
       # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
     end