Rundun Runs API
You use the rundun runs api to start, check, and stop automated jobs through web requests. Teams set this up by creating an account role and issuing an API key. Most engineers give this single key broad rights so build scripts never fail. Broad keys create a big risk if a script runs a bad command. How the rundun runs api works in practice The native workflow starts when a user or build tool sends a web request. This request holds a secret key or token in the header. The server checks this ke
API Key Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You use the rundun runs api to start, check, and stop automated jobs through web requests. Teams set this up by creating an account role and issuing an API key. Most engineers give this single key broad rights so build scripts never fail. Broad keys create a big risk if a script runs a bad command.
How the rundun runs api works in practice
The native workflow starts when a user or build tool sends a web request. This request holds a secret key or token in the header. The server checks this key against its internal list of valid accounts. If the key matches, the server checks the role tied to that account.
A role is a set of rules that says which jobs can run. Once the role check passes, the system puts the job into a work queue. Worker nodes pick up the task from the queue and run the steps. Each step runs on a target host or database using stored secrets.
While the job runs, the system writes output lines to a central log file. A user can send another web request to read the job state and log output. The system returns whether the task is waiting, running, done, or failed. Teams can also send a stop request if a task hangs for too long.
What native roles solve and where gaps remain
Native roles are great for sorting out which team owns which set of jobs. You can let the billing team run payment tasks while blocking the web team. You can also let junior staff read job logs without starting new tasks. This stops simple mistakes inside the main dashboard and keeps projects neat.
Still, native role checks stop working the moment a job starts to run. The role only decides who can press the start button or send the call. It does not check the actual commands or queries inside the running task. If a job accepts user input, a developer can pass in risky parameters.
Shared API keys make this problem much worse for growing engineering teams. When five build pipelines share one key, audit logs show the same bot name. You cannot tell which person approved the build or changed the job input. Also, those keys often sit on developer laptops or inside plain text files.
API Key Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to tighten job execution and key management
Start by breaking apart large jobs into small, single-purpose tasks with fixed inputs. Never allow an API call to pass raw shell commands as job inputs. Instead, use fixed drop-down lists or strict input rules inside the job setup. This stops callers from turning a basic update task into a system wipe.
Next, give every single build pipeline and script its own separate account and key. Do not share one master token across your whole engineering group. When a key leaks, you can turn it off without breaking other pipelines. Clear account names also make your system logs much easier to read later.
Finally, review the logs and data that come back from your job runs. Tasks often print customer emails, phone numbers, or card numbers into the standard output. Anyone with read rights on the API can pull those logs and read them. Set up data masking so matched fields get rewritten before logs save to disk.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How do I track who triggered a run through the API?
Give each service or user a distinct identity instead of sharing one master token. Pass the caller identity in the request metadata so audit logs record the real person.
How can I stop sensitive data from leaking in run logs?
Keep tasks from printing raw database rows to the screen during a run. Use automated masking rules that rewrite emails, phone numbers, and card numbers in results.
What happens if an API key for job runs gets leaked?
An attacker with that key can trigger any job allowed by the attached role. Revoke the leaked key right away and check your logs for odd job runs.