Marketplace integrations and custom snippets often need an API key, token or password to call another service. Keep the credential value in AWS Secrets Manager or Cloudflare Secrets Store, and use a named reference in your journey configuration.
The same mechanism works across integrations: you choose a name, map it to a secret on the deployment target, then use that name wherever the integration accepts a runtime secret expression. Packages that do not call an authenticated service may need no credentials.
How the pieces fit together
| Field | What it identifies | Example |
|---|---|---|
| Store name | Your label for this store in the target configuration | integration_credentials |
| Store ARN or Store ID | The AWS secret or Cloudflare store containing the values | Copy this from your cloud account. |
| Darwinium Secret Name | The name your journey references | service_api_key |
| Keystore Name | The key to retrieve from that store | API_KEY |
The names are configuration; the actual API key stays in the secret store until retrieved for use. A single target can have several mappings, including credentials for different services. Give each Darwinium secret name a unique name across the target's stores, using letters, numbers and underscores.
For example, identity_api_key, messaging_token and internal_api_key can each resolve to a different credential. An integration requiring a username and password can use separate mappings for each value.
1. Store the credential
Use the store supported by the target that will execute the integration.
Cloudflare targets
Create the credential in Cloudflare Secrets Store and give it the Workers permission scope. Record the store's ID and the secret's name. Here, Keystore Name means that secret name—not its value or its ID. See Cloudflare's Secrets Store setup.
AWS targets
For CloudFront or AWS Outpost, create an AWS Secrets Manager secret whose SecretString is a JSON object with string values. For example:
{
"API_KEY": "your-service-api-key",
"API_USER": "your-service-account-name",
"API_PASSWORD": "your-service-account-password"
}
Include only the values your integration requires. Record the secret's ARN. Here, Keystore Name means a JSON key such as API_KEY; the Store ARN identifies the AWS secret containing that object.
The execution role needs secretsmanager:GetSecretValue for the secret. A customer-managed KMS key also requires the corresponding kms:Decrypt permission. See AWS secret retrieval permissions.
2. Map the credential on the deployment target
- In Darwinium, select the relevant node and open Node Settings → Edge Deployment (labelled Targets in some Portal versions).
- Open the target that will run the integration and find Secret Management.
- Add a store, give it a Store name, and enter its Store ID for Cloudflare or Store ARN for AWS.
- Select Add mapping. Enter the Darwinium Secret Name you want to use in your journey and the corresponding Keystore Name.
- Add further mappings as needed, then save with Update.
These screenshots show example identifiers, not credentials. Configure mappings separately on each deployment target. The journey can use service_api_key in both test and production while each target resolves it to its own environment's credential.
3. Reference the name in the integration
After adding a snippet to a step, open its configuration and identify the credential argument described by that integration's guide. Where that argument accepts a runtime secret expression, enter:
{{ secret(service_api_key) }}
Use the Darwinium Secret Name, not the store ID, ARN, provider key or credential value. Repeat with the appropriate name for each credential the integration needs.
The reference supplies a value; the integration still determines how to authenticate. An API key might go into a header or body field, a bearer token into an Authorization header, and a username/password pair into Basic authentication. Follow the package's argument descriptions so you do not add a prefix or encoding that the template already supplies.
When making your own integration, place the reference in the outgoing request template where the service expects it. Templates that quote or encode credential arguments during snippet expansion need particular care: the secret expression must still be evaluated at runtime. See Snippet references and arguments for template composition and Basic-auth examples.
4. Deploy and verify
Build and deploy the journey to the target with the mappings. Test a controlled interaction and confirm that the provider accepts the request and that the expected response is mapped into the event. Keep credential values out of event attributes and diagnostic output.
If authentication fails, check the target and environment, the Darwinium name, the provider key or JSON key, store permissions, and the authentication format expected by the service. A successful deployment alone does not prove the credential is valid for that service.
When rotating a credential, update its value in the store. Existing names can stay the same; changes to store locations or mappings require the corresponding target configuration and deployment changes. Running workers cache secret values, so verify the new credential after refresh rather than assuming an instantaneous switch everywhere.