Skip to main content

Overview

A source’s secrets (passwords, private keys, access keys, authentication headers) can be replaced with a single request, without reconfiguring the source or publishing a new version. Use it when a credential expires, leaks or is rotated by your provider. The request only changes the secrets you send. The rest of the source configuration is kept, and secrets are never returned in API responses.

Secrets by source type

Only the fields listed below are accepted. Nested fields use a dotted path.
URL header names are matched regardless of case: options.headers.authorization replaces a stored Authorization header instead of adding a second one. Headers that are not listed above cannot be changed with this request.

Rotate secrets

Before you begin, set these values: The secrets object maps each secret field to its new value. This example rotates the credentials of an SFTP source:
  • A field set to a value replaces the stored secret. A field set to null removes it. A field you omit keeps its current value.
  • Multi-line values (private keys in PEM or armored format) must keep their line breaks, written as \n inside the string.
  • Rotate paired secrets in the same request, for example accessKey and secretKey on S3, or pgpPrivateKey and pgpPassphrase.
  • The new secrets apply to the live version of the Datasource, its draft and any version awaiting verification. The previous secrets cannot come back with a later publication.
A 204 status confirms the change. A field that is not a secret of the source, an empty secrets object or an unknown SOURCE_INDEX returns 400, and nothing is saved.
When the result contains a pgpPrivateKey, Reelevant checks that the key can be read and unlocked with the passphrase before saving anything. An invalid key or a wrong passphrase returns 400. See PGP Decryption. Other secrets are saved as sent and are checked by the next import.

After the rotation

The request does not start an import. A scheduled Datasource uses the new secrets from its next import. To check them immediately, trigger a new run of the Datasource and review its logs. For a continuous (ingester-mode) Kafka Datasource, there is no next import: review its logs after the rotation.