chore: update Terraform reference: sync service_account_api_key for v0.9.4

[mintlify]

Summary

Align the kosli_service_account_api_key reference page with the upstream v0.9.4 release of terraform-provider-kosli.

Changes

• Sync example usage with the shipped resource.tf for v0.9.4 (adds explanatory comments; example expiry moved to 2027-01-01T00:00:00Z).
• Rewrite the Expiry section to match upstream wording: state the 365-day cap, name the exact Terraform error (Provider produced inconsistent result after apply), and warn against deriving expires_at from timestamp().
• Note that expires_at is null only for keys minted before the 365-day cap was introduced.
• Update the expires_at schema example timestamp to match.

Context

Reflects v0.9.4 (September 11, 2026), which aligns the provider with the server's 365-day cap on API key expiry. No new resources or data sources; existing resource page updated in place. The changelog entry itself is left to the "Update changelog" workflow.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
kosli	🟢 Ready	View Preview	Sep 11, 2026, 8:22 PM

[claude]

Claude finished @mintlify[bot]'s task in 2m 34s —— View job

---

Doc review — PR #408

• Read the changed file at branch head (2225ab8)
• Cross-check expiry wording against the rest of the site
• Navigation / redirects / link checks
• Post findings

Three findings, all on terraform-reference/resources/service_account_api_key.mdx, posted inline. Nothing critical; this is safe to merge as-is.

#	Location	Category	Issue
1	:71	Improvement	Reintroduces a null expires_at state that eb4485e (#407) removed as impossible, with no guidance for a reader who imports such a key
2	:64-66	Improvement	The new <Warning> names the Provider produced inconsistent result after apply error but drops the consequence the old bullet carried (tainted → next apply revokes and recreates the key); also loses the "from creation" anchor on the 365-day cap that the sibling pages use
3	:68	Improvement	The timestamp() warning is a sentence fragment — "and because expires_at forces replacement that would revoke and recreate the key on each apply" never resolves

Upstream — does not block this merge

terraform-reference/ is agent-synced from kosli-dev/terraform-provider-kosli, so a fix here survives but drifts. Findings 2 and 3 are prose the next sync can overwrite — they should also land in the provider repo's page source. Finding 1 needs a decision on the provider's read path (internal/provider/resource_service_account_api_key.go) before either repo asserts it: whether a pre-cap key with a null expiry can still be read or imported.

Checks I could not run

gh pr checks and mint broken-links were not permitted in this environment, so per CLAUDE.md core rule 5 the link-rot status is unverified. The only internal link on the page is pre-existing, root-relative, and its target (terraform-reference/resources/service_account.mdx) exists. No page was added, moved, or deleted, so no config/navigation.json or config/redirects.json change is required; the ## Expiry heading anchor is unchanged.

Verdict: 0 Critical, 3 Improvements, 0 Suggestions. Advisory only — no approval or change request.
· mintlify/bc9f6480

[claude]

Improvement — the timestamp() warning is missing its main clause, so the reason it matters is hard to parse: "It changes on every plan, and because expires_at forces replacement that would revoke and recreate the key on each apply." The consequence sentence never resolves.

Suggested change

	To derive dates from a fixed anchor, use Terraform's built-in functions, e.g. `timeadd("2027-01-01T00:00:00Z", "720h")`. Avoid deriving `expires_at` from `timestamp()`. It changes on every plan, and because `expires_at` forces replacement that would revoke and recreate the key on each apply.
	To derive dates from a fixed anchor, use Terraform's built-in functions, e.g. `timeadd("2027-01-01T00:00:00Z", "720h")`. Don't derive `expires_at` from `timestamp()`: it changes on every plan, and because a change to `expires_at` forces replacement, every apply would revoke the key and mint a new one.

Since this page is agent-synced from kosli-dev/terraform-provider-kosli, the same wording should land upstream or the next sync will reintroduce it.

[claude]

Improvement — this reintroduces a null expires_at state that the previous commit on this page deliberately removed. eb4485e (#407) deleted the "null for a key that never expires" callout with the stated reason that the state "can no longer exist", verified against kosli-dev/server (src/model/api_key.py::clamp_expires_at, MAX_API_KEY_LIFETIME_DAYS = 365).

Two problems as written:

1. Nothing else in the docs supports the claim that pre-cap keys with a null expiry still exist in Kosli — the expires_at schema entry (line 96) doesn't mention null, and client_reference/kosli_create_api-key.md:16 states flatly that every API key expires.
2. If such keys do exist, the page gives a reader who imports one no guidance: does Terraform show permanent drift, and does setting expires_at on it force replacement (i.e. revoke a working key)?

Either confirm the legacy state against the provider's read path and say what a reader should do with one, or drop the sentence.

[claude]

Improvement — the rewrite names the error but drops what happens after it. The replaced bullet told the reader the resource is marked tainted and the next apply revokes and recreates the key; without that, someone who hits Provider produced inconsistent result after apply doesn't know their key is about to be rotated out from under them. Also, "365 days" loses the anchor that the sibling pages carry ("365 days from creation" — administration/authentication/api_key_rotation.md:14, tutorials/rotating_api_keys.mdx:23).

Suggested change

	<Warning>
	Kosli caps the lifetime of every API key at **365 days**. An `expires_at` further out than that is silently shortened by the server, and Terraform then reports the mismatch as `Provider produced inconsistent result after apply`. Keys that never expire can no longer be created: omitting `expires_at` yields the maximum 365-day expiry rather than no expiry at all.
	</Warning>
	<Warning>
	Kosli caps the lifetime of every API key at **365 days from creation**. An `expires_at` further out than that is silently shortened by the server, and Terraform then reports the mismatch as `Provider produced inconsistent result after apply` and marks the resource tainted — the next apply revokes the key and creates a new one. Keys that never expire can no longer be created: omitting `expires_at` yields the maximum 365-day expiry rather than no expiry at all.
	</Warning>