Hook (1-2 sentences): Domo CodeEngine stores your functions inside the platform — which means no diffs, no pull requests, and no history unless you pull them out yourself. Here's how to extract every CodeEngine package and function into version-controllable text files using domolibrary.
Why It Matters
CodeEngine is powerful, but platform-native storage creates a blind spot: you can't review changes, collaborate via GitHub workflows, or audit what's actually running in production. Pulling functions out programmatically means you can treat CodeEngine the same way you treat any other codebase — with commits, code review, and a paper trail. It also gives you a readable snapshot of Domo's own internal packages, which turns out to be useful for understanding which APIs they're actually calling under the hood.
What You'll Learn
- Authenticate against the Domo API using a token-based
Authobject fromdomolibrary - Query CodeEngine packages with
DomoDataCenter.search_code_engine()to retrieve the latest version of each package - Parse and filter versions to only include packages where functions can be extracted
- Export packages by ID and by name using a
handle_get_packageexport handler - Inspect Domo's own internal API usage (V1, V2, V3 data source endpoints) from the exported function code
Extracting CodeEngine Functions: Patterns and Implementation Details
The workflow is built around two core abstractions in domolibrary. First, a TokenAuth object handles credential management — you instantiate it once and pass it downstream to every API call. Second, DomoDataCenter wraps Domo's query API and exposes search_code_engine(), which returns a list of DomoVersion objects representing the most recent version of each package.
Each DomoVersion carries a package_id, the language, an optional description, and most importantly, the parsed list of functions extracted from the package's code. The filter step — dropping versions where functions can't be parsed — is worth noting: not every package exposes clean function boundaries, so building in that gate keeps the export clean.
The export step is handled by handle_get_package. Because versions don't carry a human-readable name, you need a separate call to fetch the parent DomoPackage to get package.name — a minor two-step that's worth folding into the class if you're iterating on this. The result is a folder of exported files, one per package, keyed by both ID and name.
One unexpected payoff from running the export: you can read Domo's own first-party packages. The dataset package, for example, shows Domo internally calling V1, V2, and V3 data source endpoints — datasource/v3/{id} for metadata, upload endpoints for data — which is useful context when you're building connectors or debugging API behavior at the platform level.
The full notebook is available in the domolibrary repo.
