Collections and Outputs

A loop keeps what its runs produce in collections: named sets of records with declared fields. It sends a result out of the platform through its outputs: a signed webhook to your system, or an email.

Declare a collection

A run may write only the collections its loop declares:

collections:
  - name: leads
    key: email
    fields:
      email: string
      company: string
      company_size: string
      score: number

Key	What it says
`name`	The collection’s name, such as `leads`.
`key`	The field that identifies a record. Its value becomes the record’s id.
`fields`	Each field and its type: `string`, `number`, `boolean` or `date`. A write that carries a field the declaration does not have is refused.
`shared`	`true` when other loops in the account may read and write this collection too.

The collection is created when you save the draft that declares it, so you can try the loop on the Chat bench at once. A run writes records with records_put and reads them with records_query.

One collection, one loop, unless it is shared

A collection belongs to the account, and its name is its identity. If two loops declare the same name, they read and write the same records. So saving a draft refuses a name that another loop already declares, unless every loop that declares it says shared: true. The refusal names the collection, the other loops, and both fixes: rename it, or declare it shared everywhere.

Change a collection

A later version can add fields: records written before simply lack them. Saving the draft refuses an edit that removes a field or changes a field’s type or key, and names the fields: keep them, or declare a new collection.

Read your records

Collections in the console shows the records your loops wrote, collection by collection. To show them on a page of your own design, write a page.

To serve records to another server, create an API with New API on Schedules, then open it there and press its Mint a key for button, which names the API. See Collections in the API reference.

Outputs

outputs say where a result goes when something happens in a run. A run with no user must declare at least one.

A webhook

outputs:
  - kind: webhook
    event: run.ended
    url: https://crm.example.com/hooks/pio

When a run ends, the platform POSTs a short JSON body to your url: the event, the loop and its version, the run, and how it ended. The body carries identifiers, never text a model wrote; read the run itself through the run API. Each delivery is signed with the loop’s webhook signing secret, shown on the loop’s Keys tab. Webhooks shows the body, how to check the signature, and the retries.

An email

outputs:
  - kind: email
    event: run.ended
    to: sales@example.com

When a run ends, the platform sends an email to to, but only to a verified recipient:

An address that belongs to a member of your account is verified already.
Any other address gets one confirmation email from plutonium.io when you publish the loop. It receives nothing from the loop until that person confirms. The link in the confirmation is valid for 7 days.
Every email carries a one-click unsubscribe link. After an unsubscribe the address gets nothing more, and adding it again needs a new confirmation.

Delivery status

On Loops, each webhook or email output says how its deliveries are doing: how many failed, how many are waiting or retrying, and the last error. A delivery that fails never changes how the run ended.