A Final Build is delivered to one private Signaliz workspace as a reusable system. Your team can inspect the contract, run the approved workflow again, retrieve results, and use the interfaces included in the blueprint.
Delivery options available now
Delivery | What you receive |
Signaliz workspace | Private build contract, run access, evidence, results, and receipts. |
CSV | A clean reviewed download using the delivered output fields. |
Webhook | A live trigger or delivery endpoint and returned result included in scope. |
REST API | Workspace-authenticated endpoints to list, inspect, run, and recover the build. |
MCP | Tools that let a supported AI client list, inspect, price-check, run, and recover delivered builds. |
CLI | Commands to operate delivered builds from a terminal. |
Slack and Google Sheets delivery are marked Coming soon as of August 3, 2026. Do not rely on them until the live build surface and blueprint show that the customer-owned connection is provisioned.
What “built in Clay” means
Clay is the disclosed workflow execution technology. Signaliz is the orchestration, workspace, contract, billing, proof, and delivery layer around the build.
Depending on scope, Signaliz may build in its managed Clay environment or in the customer’s Clay workspace. “Build in your Clay” is included in Embedded GTM Engineering and can be scoped separately for other work. A visible Clay table or workflow is not, by itself, a completed Signaliz delivery.
What belongs to the customer workspace
Only the workspace assigned to the Final Build can list, inspect, or run its BLD-... ID. A different workspace receives NOT_FOUND even if the ID is valid. This prevents a delivered system and its results from being exposed across customers.
The handoff should include:
build name, outcome, lane, and Final Build date;
input and output schemas;
delivery notes and operating runbook;
tested routine assignment;
measured Clay-credit budget per run;
fixed Signaliz-credit price per run;
supported delivery interfaces;
known limits, exceptions, and locked actions.
Access and secrets
Customer-system access is designed during the blueprint and provisioned only after approval.
Use the least-privileged account, OAuth grant, API key, or service role that can complete the approved action.
Create separate credentials for Signaliz instead of sharing a personal administrator credential.
Do not put passwords, API keys, private keyed MCP URLs, or tokens in the public request form, attachment, email, or support chat.
Record which workspace, system, and environment each connection can access.
Define how access is rotated or revoked and include a rollback plan for connected builds.
Operating responsibility after handoff
Signaliz is responsible for delivering the system described in the accepted blueprint and for making its included run surface observable. Your team remains responsible for approving the business use of returned records and any downstream action outside that build’s explicit contract.
An export proves that Signaliz produced a handoff. It does not prove that a CRM, sequencer, spreadsheet, or other destination accepted or acted on it. Preserve the destination system’s receipt separately.
Next: Run a delivered managed build.