Embed a CloudBees CodeShip integration in your product

Enable the CloudBees CodeShip connector in your fastn dashboard, then let each customer authenticate their own CloudBees CodeShip account. fastn handles the OAuth flow, token storage and refresh per tenant, so there is no CloudBees CodeShip client code in your app and no per-customer branch in your codebase. Setup is 4 steps.

Yes. Every integration is scoped to the individual customer, so each authorises their own CloudBees CodeShip account and only ever sees their own services, builds and deployments. That per-tenant isolation is the point of an embedded integration: you support the long tail of customer setups without maintaining an integration per customer.

Yes. The same integration is exposed to your agents through the fastn MCP gateway, with permissions scoped per tenant and every call audited. An agent reads recent build failures before triaging. A prompt that works on day one: "List projects whose last three builds all failed and the first failing step in each."

fastn does. When CloudBees CodeShip changes an endpoint, deprecates a field or alters its auth, the fix lands in the connector rather than in your backlog, and your customers' integrations keep working.

Yes, through event triggers. Events are delivered per tenant and can be replayed after an outage, so a webhook missed during downtime is not silently lost.

Yes, within scoped permissions, and every action is audited so an agent's changes are attributable.

A common starting point: read projects and recent builds into your product. Teams also use it for the other use cases listed above, and expose it to agents for governed reads and writes.

It is included. Pricing is based on customer connections, not on how many connectors you enable, so adding CloudBees CodeShip does not change your cost. You can start free with 3 customer connections.