Managing one Domo instance via the API is straightforward. Managing a dozen — each with its own access token, host URL, and account object — is where most automation scripts fall apart.
Why It Matters
Without a consistent pattern, every function you write has to solve authentication from scratch for each instance. That means duplicated logic, brittle credential handling, and no clean way to fan out a single action across all your subscribers. A structured "sudo" pattern centralizes auth so your instance-specific logic stays focused on what it actually does — not on how to prove it's allowed to do it. For teams managing multi-tenant Domo deployments, this is the difference between a script that works once and a system that runs unattended.
What You'll Learn
- Build a reusable Code Engine library that dispatches API calls across multiple Domo instances
- Structure account objects so instance name maps directly to stored access token credentials
- Centralize authentication in a single
get_datafunction used by all action methods - Pass Domo instance context into each function to reconstruct the correct account name at runtime
- Separate "what to do" logic from "how to authenticate" so new actions are easy to add
Centralizing Auth with a Dispatching Pattern
The core insight here is naming convention. Each Domo instance gets a corresponding Code Engine account object named with a predictable pattern — something like SDK DataCrew Space or SDK Domo Community. When you call any action function (like get_collections), you pass in the target Domo instance name. The function reconstructs the account name from that string, pulls the stored access token, builds the correct host URL, and fires the request.
All of that plumbing lives inside a single get_data helper. It accepts a method (GET, POST, PUT), a constructed URL, and optional payload — and handles authentication transparently. Every action function in your library calls get_data rather than managing credentials directly. Adding a new action — say, updating users or setting host URLs — means writing a function that knows what endpoint to hit and what payload to send, not one that also has to figure out how to authenticate.
The practical result: to run an action across all your subscriber instances, you loop over a list of instance names and call the same function each time. The dispatching layer does the rest.
This pattern was built for Code Engine but the underlying structure applies anywhere you're managing multiple Domo instances from Python — Jupyter Notebooks, scheduled jobs, or internal tooling. The main thing to adapt is how account objects are stored and retrieved in your execution environment.
