Testing & Executing

Overview

Testing happens directly inside the Tool Editor, in the Test panel of the Code step. The same code you test there is the code that runs when callers invoke your tool, so test results reflect real runtime behavior.

Once published, your tool can be executed from its marketplace page or programmatically through the Rival API.

The Test panel

In the Tool Editor, open the Code step. At the top of the step you’ll see a mode toggle:

• Test - create and run test cases against your draft code.
• Publish - prepare release notes, set visibility and pricing, and ship the version. See Versions & Publishing.

Stay in Test mode while you’re iterating.

Test cases

A test case is a concrete example input that can be executed against your tool. Each one is tied to an event in your input schema.

You can build test cases two ways:

• JSON editor - paste or hand-write the event payload as structured JSON.
• Form builder - fill in fields based on the schema you defined.

Both produce the same payload shape. Saved test cases double as default examples users see when they execute your tool from the marketplace page.

Tip

Add multiple test cases that cover the boundary conditions of your tool - empty inputs, large inputs, the obviously-happy path, and any inputs that should fail gracefully.

Running a test

Pick a test case, click run, and the panel shows you the response. The output includes the result your handler returned, a status code, and any error message. Errors are returned in the response body rather than written to a separate log, so the test panel is your primary debugging surface.

If a run fails, fix the code, save, and re-run the same test case. Iterate until every test case passes.

Caution

Publishing is blocked until at least one test case has passed. Make sure your tests cover the cases you care about, not just the ones that happen to succeed.

Executing a published tool

Once you publish, your tool can be run by anyone with access to it.

From the marketplace page

A published tool gets a detail page at cortexone.rival.io/marketplace/{org}/{tool-name}. From that page, users can:

• Select a version
• Pick an event and supply inputs (or use one of your saved test cases as a starting point)
• Run the tool and see the response

This is the fastest way to demo a tool or to let non-developers try it.

Via the Rival API

Tools can also be executed programmatically. Open the tool’s detail page and use the API tab to get the endpoint, sample request, and required headers. See APIs for the full reference, including authentication, request/response shape, and version pinning.

Selecting a version at runtime

By default, callers hit the latest published version. For production integrations, pin to a specific version so a future release can’t change behavior under you. Pinning is done by including the version in the request - see the APIs doc for syntax.

Execution history and usage

Every run is recorded against your workspace. View past runs from:

• My Tools (/my-tools) → Run History tab - per-run details across all tools you’ve built or used.
• Manage Billing → Transactions & Usage - aggregated usage for billing.

Each entry includes tool name, version, duration, and cost. Use these to track spend; use the Test panel for debugging.

Credits

Every execution consumes credits from your workspace. Cost depends on tool pricing, runtime usage, and execution complexity. If your balance is zero or negative, executions will not run.

Caution

Keep a positive balance on your workspace to avoid failed runs. See Run Balance.

Best practices

• Treat test cases as part of the tool, not a throwaway step. They live with the tool and act as examples for users.
• Cover edge conditions explicitly - empty inputs, large inputs, expected failures.
• After publishing, monitor the Run History tab for failures and iterate via new versions instead of editing in place.

Next steps

• Publish your tool
• Call your tool from code
• Deprecate or delete a version