Authoring Extensions

Publishing your own extension means describing one external API call precisely enough that any consumer can run it from a rule. You fill in the details once, and the engine turns them into a valid, runnable extension that others can pick up and use.

How an extension comes together

You describe a single call — what to send, where to send it, and what comes back — and the engine assembles a self-contained extension from that description. You do not have to wire up the underlying logic, references, or identifiers by hand; the engine handles the details that are easy to get wrong so the result is valid and ready to publish.

An extension description captures:

• Identity — a name, category, and description so consumers can find and understand the extension in the marketplace.
• The request — the method and URL of the call, along with any URL segments, query parameters, headers, content type, and request body it needs.
• Authentication — how the call proves who it is: unauthenticated, an API key in a header or query string, or OAuth2 client credentials.

Inputs, managed parameters, and outputs

An extension separates three kinds of value. Inputs are supplied by the caller on every run. Managed parameters are named secrets or configuration — API keys, OAuth client credentials — that the installing organization maps to its own environment variables, so secrets never live inside the published extension. Outputs are the values returned to the calling project, with the first output receiving the response from the call.

Because authentication flows through a managed parameter, the same extension works across organizations: each one supplies its own credentials from its own environment, and you never ship a secret inside what you publish.

Starting from an API description

If the service you are wrapping publishes an OpenAPI or Swagger description, you do not have to transcribe it. The engine can read that document and turn a whole API into a family of related extensions — one per operation — that share a category and a managed credential. See OpenAPI Import for the single-action version of the same idea.

Returning results

An extension runs as its own rule set, separate from the project that calls it, so it needs a way to hand results back. When an extension is set up to return data, the engine sends its declared outputs back to the calling project automatically as the extension finishes, and those values flow into the caller's context — letting a packaged extension behave like a function the caller reads a result from.

Versions and publishing

Authoring follows the same lifecycle as consuming. You create the extension, edit it as a draft, and publish a version when it is ready. Each publish produces a new immutable version while earlier ones keep working, so consumers pinned to a prior version are never disrupted. You can also start a new extension from a copy of an existing one. When you publish, you choose whether the extension is public — eligible for the marketplace — or private to your organization.