Code tools and connections

Code tools

Package private Python as a tool. The buyer gets the result; the code runs sealed server-side and never leaves the server: not in responses, not in errors, not in logs.

Runtime limits, packages, and isolation are covered under The sandbox below.

Which connection do I need?

Two mechanisms reach outside APIs, and the choice hinges on who makes the call.

• The model itself calls the API, as one of its toolsa custom API connection
• Your own Python calls it, from inside the sandboxa sandbox host

The sandbox chain is next, then the files your tool produces; custom API connections close the page.

The sandbox

Skill code runs in an isolated cloud micro-VM, one per buyer session, created fresh and torn down after. It has no internet access by default: raw sockets and DNS are blocked outright, and the only way out is HTTP to domains you declared, enforced by a gate that lives outside the sandbox, so code inside cannot reroute around it.

Inside: Python with the standard library, numpy, pandas, matplotlib, pypdf, Pillow, cryptography (hashing, digital signatures, symmetric and asymmetric encryption, certificate handling), and psutil. No package installs at run time. A tool call gets 25 seconds; output is capped (5 MB per file, 10 MB and 20 files per run) so results come back as artifacts, not floods. Buyers see results and never the code, the logs, or the error internals.

Code that calls a credentialed API uses a named credential bound to one of those declared hosts. You assemble the chain under Settings → API keys: store the key once as a credential, add the host, bind the two, then attach the host to an expert in the builder. Your code reads the value as EV_KEYS['NAME'], a plain dictionary handed to your tool at run time, never an environment variable: for a credential named CRM_API_KEY the read is token = EV_KEYS['CRM_API_KEY'].

Five actions assemble and verify that chain, walked below.

Add a credential

Under Settings → API keys, add a credential: the name your code passes to EV_KEYS and the secret value. Only a masked hint is ever shown back, never the value. The credential also carries the choice of who pays, set once here: leave it on your stored key, or mark it buyer-supplied and buyers add their own value for that expert, named on the listing before they hire. There is no per-expert toggle for this; the choice rides with the credential everywhere its hosts are attached. A credential alone does nothing yet: its card reads No hosts bound yet until you join a host to it.

Add a host

Add the exact hostname your code tools may reach. The add-host modal already carries a credential picker, so the bind usually happens right here; leave it on None and the host is egress only, reachable but injecting no key. Wildcard hosts such as *.example.com are accepted for the sandbox and flagged at inspection, so broad egress is always a visible, deliberate choice.

Bind or rebind from the host row

Skipped the picker? Every host row on the Keys page carries a credential select: pick a credential to bind it, pick another to rebind, or set it back to egress only. Each host injects at most one credential at a time, while one credential can unlock any number of hosts. Rebind at any time: draft experts pick the change up immediately, published experts keep their frozen snapshot until you republish.

Attach the host in the builder

In the builder's Compose step, tick the host under Sandbox hosts to attach it to the expert. Attaching joins the host to that expert's egress allowlist and, when a credential is bound, injects its key into the sandbox at run time. Experts attach to the host, never to the credential directly, and buyers see the hostnames on the listing.

Verify the keys line up

The same Compose step verifies the chain. If a code tool reads an EV_KEYS name that no attached host supplies, a missing-key advisory names the tool and the key so you can bind it before a run hits an empty slot; once every key your code tools read is supplied by an attached host, the advisory flips green. That green line is how you know the setup is finished.

Files your tool produces

Anything your code writes under outputs/becomes a downloadable artifact of that run, held on the server until the buyer fetches it. Nothing is ever written to their machine, so say "available as a run artifact", never "saved to your computer".

In the buyer's artifact archive, images (PNG, JPEG, GIF, WebP), short videos (MP4, WebM) and audio (MP3, M4A, WAV) play inline; every other type is download-only. SVG is download-only on purpose: it can carry script, so it is never rendered inside the buyer's page. Video and audio sit under the same 5 MB per-file cap as everything else, and the file is fetched whole before it plays rather than streamed, so produce short clips.

The platform does not generate media for you. An image or a video comes from your own API call, either api_call through a granted connection or your code tool calling a declared domain or an attached sandbox host, and you write the bytes it returns straight to outputs/. Pillow is there for the work after that: resizing, cropping, compositing, format conversion, thumbnails.

Custom API connections

A connection lets your expert call an outside API on its own, without ever holding the credential. Where the sandbox chain above is three pieces you assemble, a custom connection is one object, created on one screen and granted on another.

Step one: create the connection

Under Settings → API keys, Add new connection collects everything in one modal: a name, the exact hosts it may reach, the env var name buyers will see, the key itself, and the auth style (bearer token or a custom header). One save creates the whole object; wildcards are rejected at inspection, so a connection's hosts are always exact.

Step two: grant it to an expert

In the builder's Compose step, tick the connection to grant it to the expert. The same row carries the per-expert choice of whose credential each call uses: yours, and you absorb the cost, or the buyer's, and the listing tells them which key to add. Unlike a sandbox credential, this choice is made per expert, on the grant.

At run time the expert requests a call, a broker checks the host against your allowlist, injects the credential server-side, and returns the response. The model never sees the key; neither does the buyer. Requests are capped small and time-boxed, so a connection stays tightly scoped: a few named hosts, small payloads, no open pipe out.

Connections cover calls the expert makes on its own. When your own code tool makes the call instead, use a sandbox host with a bound credential, covered in The sandbox.