Why does Haystack take an API key as Secret.from_env_var, not a string?

## The problem being solved Haystack's central promise is that a pipeline is a first-class, inspectable object: you can serialize it to a dict or a YAML file, check it into a repository, diff it in review, ship it to another environment and load it there. That promise collides head-on with credentials. If the API key a generator was constructed with is just a `str` attribute, then the moment you serialize the pipeline the key is in the file — and files get committed, attached to tickets, pasted into chat, and copied into logs. The `Secret` type is the type-level fix. Credentials are not strings in Haystack; they are `Secret` objects, and the type knows whether it is safe to write down. ## The two constructors **`Secret.from_env_var("OPENAI_API_KEY")`** stores the environment variable's name, not its value. It resolves lazily: `resolve_value()` reads the environment at the moment the value is needed. Because the object only holds a name, serializing it produces a harmless reference — the deployment supplies the value. **`Secret.from_token("sk-...")`** stores the literal secret. It resolves to that value, and it is convenient in a notebook or a quick script. Both are consumed identically by components: `OpenAIChatGenerator(api_key=Secret.from_env_var("OPENAI_API_KEY"))`. In fact most provider components default their `api_key` to the conventional env-var secret, so the common path is to set the variable and pass nothing. ## The asymmetry that is the whole point Only env-var secrets can be serialized. Calling `to_dict()` on a component holding a token secret raises rather than emitting the key — Haystack's documentation shows exactly this as an error case. That is not an oversight to work around; it is the guard rail. The type system refuses to let you export a pipeline whose definition would contain a live credential. The practical consequence for design: if a component of yours takes a credential, take it as a `Secret`, not a `str`. Accepting a raw string quietly opts your component out of the protection, and a reviewer scanning for leaks will not see it. ## Round-tripping On serialization, the env-var secret becomes a small dict describing which variables it reads. On the way back, that dict must be turned into a `Secret` again before the component is constructed, or `__init__` receives a plain dict where it expected a credential object. Haystack provides `deserialize_secrets_inplace(data["init_parameters"], keys=["api_key"])` for exactly this: call it in your `from_dict` before delegating to `default_from_dict`. Forgetting it produces a confusing failure at load time in which the component appears constructed but the credential is unusable. ## The strict flag `Secret.from_env_var` takes `strict`, defaulting to `True`, which makes resolution raise when the variable is unset. That is usually what you want: a missing credential should fail loudly, at the point the pipeline warms or first runs, rather than surfacing as a 401 from a provider three layers down. Setting `strict=False` resolves to `None` and lets a component fall back — useful for optional credentials, dangerous as a default habit. It also accepts a list of variable names, so a component can look for several conventional names and take the first one set. ## Why an interviewer asks this Because the answer separates people who have shipped a Haystack pipeline from people who have run a tutorial. The tutorial path never serializes anything, so `from_token` works fine and the distinction looks academic. The production path — pipeline definitions in version control, promoted between environments, loaded by a service — makes the distinction load-bearing. The good answer connects the type to the workflow: the pipeline file is an artifact you want to share, so the type must guarantee it contains no secrets, and lazy resolution is what makes the same file valid in staging and production with different keys. ## Adjacent good practice worth naming Being a `Secret` does not stop you leaking the value elsewhere: `resolve_value()` returns a plain string, and anything you do with it afterwards — logging it, putting it in an exception message, echoing a config dump — is on you. Resolve as late as possible, never store the resolved value on the instance where `to_dict()` might pick it up, and rotate by changing the environment rather than by editing pipeline files.