Extending Floyant with your own services

What a connected service is

A connected service is one you operate — on your own infrastructure, under your own control — that the platform calls over a documented interface. Your code stays yours while the platform orchestrates the call.

This distinction matters for both sides: you keep full control of your service's code, runtime, and data; the platform keeps a clear boundary around what executes inside it.

How it fits in

• The service is registered with the platform, including its address and authentication
• Automations call it as a step — request in, response out — alongside built-in steps
• Credentials for the call are managed and scoped like any other outbound integration
• The service's behavior is its own release cycle; the app only depends on its documented interface

What it is good for

Domain logic beyond the platform's scope: a proprietary scoring model, a document processor, a legacy system adapter. Anything that is genuinely yours to run stays yours — Floyant calls it as part of an automation rather than absorbing it.

The clear boundary

Connected services are deliberately simple: each one is a service you explicitly register and operate. Your code always stays with you, outside the platform.

Readable app definitions and documented interfaces give you full visibility, while the platform keeps governing what runs, data boundaries, and credentials.

Getting ready

For early access, the useful preparation is simple: identify the capability you would keep as a service, and describe the request and response it should exchange with an automation. The developers page covers the interface direction as it firms up.