This guide takes a Marketplace package from downloaded files to an operation on a journey step. Before starting, select the intended node and workspace in Workflows, and identify the interaction that should use the integration. If the journey does not exist yet, record it by browsing your site.
The installation process is shared across providers. Their individual guides supply the input attributes, credential arguments and outputs; keep that guide open while configuring the package.
1. Install the package into your workspace
In Workflows, open Darwinium Marketplace in the editor's activity bar. Find the package and select Install. Its files appear in Explorer. For example, Google Geocoding installs google_geocoding.snippet; other packages may include scripts, WebAssembly or several templates.
Keep the supporting files and their relative paths together. Before reinstalling a package you have edited, preserve your changes: installation can replace files at the same paths. Installed describes the catalogue files in this workspace; it does not mean the integration is running on a deployment.
2. Import its templates into the journey
Open the .journey.yaml file from Explorer to enter the visual journey editor. Select Snippets → Add from file and choose the installed .snippet file. The panel lists the templates it contains. A file under Available in this workspace can also be imported from that list.
Importing makes the template available to this journey. To execute it, add a use of the template to a step.
3. Add the template where it belongs
Select Add beside the template. For an operation template, select a compatible step in the placement dialog. For a whole-step template, the editor creates a new step.
| Template kind | Where to find the added configuration | Choose this location |
|---|---|---|
| API call or model operation | Step → Workflows → Models | The step that has the identity, token or other input needed by the provider |
| HTML injection | Step → Data Mappings, response HTML mappings | The HTML document response that should contain the script or widget |
| Request header operation | Step → Data Mappings, request headers | The proxied request that needs the header |
| Whole step | A new step, with arguments under Customizations | Configure its host, URL and method to match the endpoint it will serve |
For example, add an email-risk lookup to a registration submission containing the email. Add a browser widget to the HTML page containing the form. These are different steps even when they belong to the same customer flow.
4. Configure inputs, credentials and execution order
Open the added operation and fill in its arguments using the provider guide. An argument may be a literal value, an attribute path such as an email field, or a runtime template. These are different input types; pasting an email address into an attribute selector will not map the request body for you.
Map the incoming data first using data mappings. For an API request containing {"email":"alex@example.com"}, map $.email to the email attribute expected by the integration. Match its context exactly: ACCOUNT and SHIPPING, for example, select different identities.
Configure named secrets for credentials. Then set dependencies so the call runs after its input mappings. Use LOCAL.REQUEST for request-derived fields; response-derived fields require the response stage. A consuming rule must in turn depend on the integration operation. See Dependencies & execution order.
5. Decide what the result should do
The response mappings expose selected provider fields as event attributes. An enrichment call alone does not block a request or create a review decision. Add the rule or decision that uses those fields, then connect it to the appropriate action.
For an action package such as Jira or Twilio, reverse the dependency: determine whether the action is needed first, then condition the API call on that result. A page refresh or repeated submission can otherwise create another ticket or message.
6. Deploy and inspect one complete interaction
Save, resolve relevant editor diagnostics and review the changed files. Build and deploy to a test target with the required secret mappings. Exercise the flow and open the resulting event in Investigations.
Check the actual mapped input, the provider output attributes and the resulting rule or action. Test a missing input and a rejected or unavailable provider response as well as the successful case. An absent output is not equivalent to a successful low-risk result.
If nothing appears, work backwards: confirm the correct deployed journey and step matched, the operation's condition passed, its dependencies supplied the input, and the credential resolved on that target. The provider guide identifies the expected output paths.